Can not access a shared directory on another machine

ipconfig -all
Source  

Action

1) Go you the Server's System Properties / Computer Name tab / and change the computer name to SCHOOL (by way of your example, if not already) and in the same dialogue, select WORKGROUP and fill in the same workgroup name that the clients use.
2) Go to Services and see if DNS Server is running. If so, Stop and Disable the DNS Server service. (just for now, until AD attempt #2)
3) The TCP/IP Properties DNS server should point to the same DNS resolver as the rest of your network; Enable NETBIOS over TCP/IP on the server
4) If you're comfortable with it, run the AD metadata cleanup.

-----------------------------------

I don't think that your problem right now is related to remnants of DNS lurking since the AD install / uninstall. In your step 2, you state that you can ping the server from a client -- I presume by name instead of IP. If that's the case, then name resolution is working and so it's not a DNS problem. 
Are the users getting an error when they try to list or map the shares? Are they getting "Access is Denied?" Are they being challenged with a "Connect as..." dialogue? Turn off the firewall completely for further testing; you can turn it back on later, but remove the question completely for now.
What username(s) are peeps logging into the workstations with? You need to create these usernames as local users on the server. I think that when you converted to AD, it wiped out the local SAM database, and then when you uninstalled AD, it placed an empty SAM database. Even with the Everyone object having permissions, you still need the usernames defined locally on the server.
I personally think that you should go back to AD, but it may be a larger project than you were expecting at the time. You can post back for more info if you want to plan the AD conversion later.

------------------------------

Right-click My Computer, select Properties. Select Computer Name tab, click Change button. Then, click the "More" button. Verify that the "Primary DNS suffix of this computer" field is blank. If there is .tech.schoolname.edu or similar in the box, the server will register that suffix after its name as the FQDN.

------------------------------

Well then, taking one step at a time, and I'm thinking that getting your clients at least back to the way they were before, is more pressing than jumping to AD at this point.
There clearly is something wrong with name resolution if you can't even ping the server by name. If your clients can't resolve the name of the server to an IP, then we can't even think about accessing a share in the form of \\servername\sharename. 
However, you CAN test \\serverIP\sharename and see if that connects. Meaning, if your server has an IP of 192.168.50.11, then from a client, try to connect to \\192.168.50.11\sharename. If that connects, then your file sharing is OK, and you just need to fix name resolution of the server.
You are correct in that you do NOT have to put the d$ share in the UNC path; should just be \\servername\sharename or \\serverIP\sharename
Seems to me, that your server still thinks is has an FQDN of SCHOOL.tech.schoolname.org. So are you telling us that you've removed the DC role from the server, and have placed the server back into a WORKGROUP, using the same workgroup name as the clients. Confirm ALL of the TCP/IP properties on the server -- did you set the DNS server(s) back to what they were pre-AD (pre-AD sounds weird)? Are you using WINS in your org and did you check the WINS settings? Did you check if NETBIOS is enabled on the server?
I'll just briefly respond to a couple of points in your last post relative to moving forward with the AD implementation.
It is a good practice to name your AD domain name something like schoolname.LOCAL rather than using your public FQDN (SCHOOL.tech.schoolname.org). There's nothing stopping one from using their public domain name as their AD name, but as you can imagine there are considerations that need to be made for accessing public servers of the domain from internal clients. So make it easy on yourself and don't do it.
You were correct in defining DNS Forwarders in your first attempt, but missed a couple of other steps which we can talk about later.
You won't host your public DNS on the AD-controller (DC), so don't worry about that. DNS is used on the DC's to store AD-related information and to do name resolution for the organization, and is not necessarily intended to be used as your public DNS host.

========================
At least on Windows XP it does.
Look at 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters
 ======================