The problem you're going to run into is that Active Directory uses DNS to tell client machines where to find various resources, so turning off DNS on the Windows server will eventually stop things that require Active Directory from working. It sounds like it worked for a number of hours because clients had it cached, but then the cache expired.
My suggestion would be to run bind on your Linux server, and make it act as a secondary to your Windows server, and then configure your DHCP server to give out the Linux server as the DNS server clients should be using. That way, your DNS queries are offloaded onto the Linux server whilst retaining the ability to use Active Directory.
You'll need a line in your named.conf (or such) a bit like this:-
zone "ad.internal.company.com"
{
type slave;
file "/etc/bind/db.ad.internal.company.com";
masters { aaa.bbb.ccc.ddd; };
};
Not sure which version of SBS you're on, but for 2003, open up the dnsmgmt console, go to the properties for your active directory domain, and add your Linux server as a nameserver on the Name Servers tab. You'll also want to make sure Allow zone transfers is ticked on the Zone Transfers tab, along with Only to servers listed on the Name Servers tab. Additionally, you'll want to make sure that when you click Notify... (also on the Zone Transfers tab), that Automatically notify and Servers listed on the Name Servers tab are selected.
Reload (or restart) bind on your Linux server, and keep an eye on the logs, and you should see bind requesting a copy of the zonefile from the Windows server. To make sure everything's working, try making an addition to the zonefile on the Windows server and make it's propagated to bind on the Linux server.
Hope that helps!
The only real pro's and con's are the ones you've already addressed, which is continuity of the network. I usually put DHCP on the primary server (DC,DNS) so that DNS records can be automatically updated if/when a client's DHCP lease expires and it is issued a new IP address. It would take additional configuration to accomplish this task using the Sonicwall as the DHCP server.
The other side of the argument is that keeping DHCP and DNS settings on the SonicWall will allow continuity of client devices in regards to internet access. But with the server down, unless you only use hosted services, all they're going to do on the internet is mess around.
It really is up to you, but I hunted down some more opinions about the matter for you. Feel free to take a look at this and this. Basically, it's up to you, and there are caveats to each side. I personally recommend keeping it on the server.
Best Answer
Use Microsoft's DHCP if you're running Active Directory and DNS.
The Meraki's cloud management is irrelevant. Your environment is going to hinge more on the smooth operation of the Microsoft services than anything else.
A normal use case for running DHCP on the Meraki would be a home or branch office situation where there's no server presence. Not this.
The Meraki MX-series has a very basic interface and set of capabilities. So for anything more complex than the barebones DHCP functionality, you should use a server.