Domain controller migration issue


(Sarting) #1

Having an issue with freepbx failing to work after turning off our a server that used to be a domain controller.
I have switched the DNS settings on the freepbx side to the correct DNS entries, but every time we down the old domain controller, all calls just quits. I’m not sure where to start on this. Probably not even DNS related, but I don’t know what could be running on the old server that would make freepbx quit working when shutting it down.

Background, we inherited this setup from a previous admin who is no longer with the company so… yea…

Any ideas on where to start/look? We did a packet capture on freepbx’s server network port, and we saw it try to hit an old DNS one time, but couldn’t duplicate it. (which is why we thought it might be DNS related). What are some main services that would be ran on another server other than itself? I can take that and cross check everything.

Thanks guys.


(TheJames) #2

image
Perhaps the wrong gateway? What all did that server so besides everything :slight_smile:


(Sarting) #3

ifcfg-em1 - Just checked gateway, and it’s pointing to our meraki router which is correct.
any other suggestions? what could cause the calls to just stop if the server was taken offline… e.g. sql database? etc? i looked through the program list of the server and didn’t see anything that stood out… maybe there’s a php ‘hidden’ somewhere?


(Sarting) #4

And you might very well be right about the DNS thing… which places holds dns besides the ifconfig…


(Greg Kujawa) #5

That is an odd one. Perhaps on the FreePBX box see if there’s a funky static route --> ip route list

When you say all calls stop, even internal calls from FreePBX user to FreePBX user? Is the FreePBX box on the same LAN as a couple of internal FreePBX users that can try test calling each other?


(Sarting) #6

[[email protected] ~]# ip route list
192.168.101.0/24 dev eth0 proto kernel scope link src 192.168.101.8
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003
default via 192.168.1.1 dev eth1
[[email protected] ~]#

doesn’t seem odd to me. the two IPs at the top are the two network interfaces we have, but only the latter is being used (1.3)

As for the calls that stop, all calls, even the internal calls… i get a dial-tone, but when i dial an internal extension (i haven’t tried external yet as we scrambled to get the phone back up and running), it just sits in silence… no ringing…


(Jared Busch) #7

OMFG… There is no such thing as dial tone…


(Greg Kujawa) #8

So I assume that the Meraki’s LAN IP is 192.168.1.1, correct? What is/was the LAN IP of the AD controller?

Also, silly question. The FreePBX is indeed a separate physical box, right? It’s not running as a VM on the AD controller, correct? I know, dumb question but flying blind to a degree.


(Sarting) #9

Correct, LAN’s IP is 192.168.1.x. Gateway is 1.1 correct.

Old DC is 192.168.1.2.

Yes, it’s a separate physical box as well. Not on VM. Both are physical servers.


(Greg Kujawa) #10

So on the FreePBX box take a peek at the logs.

cd /var/log/asterisk
ls -l

The most recent log file from today should be entitled full. If you scroll through that then around the time of your most recent failure perhaps there’s something in there indicating what’s going on.


(Jared Busch) #11

Did you update the phones DNS also?


(Greg Kujawa) #12

Hopefully he is using DHCP for LAN clients to help make matters like DNS, GW, etc. easier. But crazier things have happened!


(Jared Busch) #13

So many people use static for insane (and inane) reasons…

The only things that should be static on a network are the router, the hypervisor(s), primary DHCP server, and primary DNS server.

Anything else that needs a fixed address can get it from a DHCP reservation.


(Sarting) #14

Yes, DHCP scope was changed since our dc also had a DHCP server as well… we switched the meraki to dish out IP’s with the correct settings. my phone is good, but i haven’t checked the others yet… will do so after… and i’ll take a looksee at the logs to see if there are any discrepancies… thanks ya’ll… new to this thing… learning a lot while troubleshooting. :slight_smile:


(Greg Kujawa) #15

Rebooting the phones will ensure they will hit DHCP and be updated. Replacing the DHCP, DNS, etc. services always requires restarting the clients and monitoring who is getting what.


(Sarting) #16

thank you sir, for good measure, going to reboot. Will report back.


(Sarting) #17

Well, finally got the time to reboot one of the pbx servers that were having issues after all the changes, and it is communicating now… however, the fax went offline -_-
If it ain’t one thing, it’s another… ugh…

Even the fax folder located at /var/spool/asterisk/ disappeared. There used to be a bunch of pdfs sitting in there and now all gone… when i call the fax DID, it gives me the fax connection tone, but no faxes are going through… and i have no idea how faxes are being processed. :expressionless:

Edit1: also, was able to read the log file… all errors are coming from 2013. i don’t see any recent errors. " No XMPP connection available when trying to connect client ‘asterisk’ [2013-06-10 15:21:28] ERROR[9336]"


(Greg Kujawa) #18

one of the pbx servers

Hmm, I thought you had a basic setup. Like one AD controller (that was replaced with a new one), one Meraki firewall/gateway, and one FreePBX box. You sure the old AD controller wasn’t running some Asterisk-type services as a VM or something?

also, was able to read the log file… all errors are coming from 2013

That means the box you are looking into might not be “the one.” If you don’t see any logged activity since 2013 at least. And if you indeed were looking in /var/log/asterisk. Look at one of the desk phone’s specs in terms of the SIP server IP/DNS name it expects to hit and whatnot. Also, your fax endpoint needs the correct DNS, SIP server, gateway, etc. all defined.


(Sarting) #19

we have 3 pbx total… 2 of them were having the same issues of taking down the DC… so i figured asking about one and if fixing that one worked, then i figured i could apply that fix to the other. And i don’t know if the DC was running any type of service, that’s what i was trying to figure out by coming here. Hoping there were some type of list or something with services that could be ran on an external server that i could check to see why shutting the DC down would cause problems. There’s no VM running on the DC.

I rebooted the phone last night and it came up with the correct info as far as the sip server/ip/DNS… all values were correct.


(Greg Kujawa) #20

Out of curiosity, if y’all have three FreePBX’es are they all at the same site location? And if so, how many extensions? I have four of my company’s sites all connecting to a single FreePBX. Maybe 150 extensions.

Let’s back things up to simplify things.

I rebooted the phone last night and it came up with the correct info as far as the sip server/ip/DNS… all values were correct.

If if “the phone” has correct values, can it make/take calls to the outside world? If so, then go to any problem endpoints that cannot make/take calls and look at their settings — network settings, SIP settings, etc. And the fax endpoint sounds like a problem child. Look at its network settings, SIP settings, etc. As @sorvani indicated, leveraging DHCP for any true clients (i.e. - not a server and not networking equipment) is the way to go. But even if you have configured a DHCP server that’s active and leasing okay, that doesn’t mean all the clients themselves are configured for DHCP. And might have static values defined instead. Case in point likely being the fax endpoint.