Whew...I missed alot in the last few days - sorry for the long delays. I'll try to answer everyone's questions to the best of my abilities, however keep in mind that there is a vast majority of information that (while I have access to) I'm not terribly knowledgable about.
When you say statically-assigned, do you mean they have been physically set in the interface's network connection properties? Has the "Obtain an IP address automatically" option been changed to a static assignment, or has the Alternate Configuration tab been set and is actively in use? You will find this information by accessing the properties of TCP/IP under the network connection's properties.
If it is still set as "Obtain an IP address automatically", this means that these addresses are being assigned by another DHCP server. These machines "shouldn't" be affected by a rogue DHCP, as the domain should have authorized DHCP set up. Take a look into it.
As for RAID, RAID 0 refers to a striped RAID, where information is striped between drives to increase performance. This however provides no fault tolerance whatsoever, and if one of the drives fail the other drive is not redundant as it only has pieces of data. RAID 1 on the other hand is mirrored, which does provide fault tolerance. If one drive fails, the other drive should have an exact copy of the failed drive and pick up where things left off.
The option for "Assign Automagically" had been changed. As I said before, there doesn't seem to be any rhyme or reason for it. The RAID, from what I understand, was using disk striping and with one failure, a good portion of the information was inaccessible. If it was *supposed* to be recoverable, it sure as hell wasn't as we had to order a new drive and rebuild the RAID before the DC was accessible outside of "Recovery Mode".
I too am suspicious of a rogue dhcp server such as a router or something else. I might also be wondering about apipa (automatic but self-assigned addresses.)
1. Could you please give us some samples of the "static" IP addresses the clients are getting, ie: 192.168.0.12 or whatever?
2. Could you also give us the scope of the dhcp in the server, for comparison?
Someone might well figure something out just by seeing those numbers.
3. Did you answer as to whether the "Obtain an IP address automatically" was actually not checked on the clients?
Last things first: To everyone's knowledge "Obtain Automatically" was selected on each of the affected machines prior to the event. The reason that I was being blamed was because I'm the only person that has spent any amount of time onsite at a few of the sites. Of course, as I said before, the idea is laughable that I would have time or inclination to hop from machine to machine to make such a ludicrous change, but some of my coworkers seem to think that's a viable option.
I'm not sure of the specific scope and stuff - but I can toss you some IPs if it will help.
The PDC uses 188.8.131.52 and is running as the DHCP server as well as the DNS server. We have other controllers at each site, but they all get their scope (from what I understand) from the above machine. Each site has a different third set of numbers - 192.242.229.xxx, 192.242.226.xxx etc. The computers at the individual sites that were affected, had the IP addresses that matched the schema (184.108.40.206) using IP addresses that would, normally, be assigned through DHCP. The difference being that they were statically assigned somehow (as mentioned above). Because of the static IP addresses, when the Domain Controller failed they were unable to pull proper records from DNS (because it's the same server) and basically lost most of their connectivity. The only reasonable solution was to log into each machine manually and change the settings back - hence the reason for "blame" in the first place.
Well, "pointing" to the wrong place and static IPs are different in my opinion. By pointing, I would think you mean the DNS server? If this is the case, perhaps it was setup incorrectly from the beginning. If the computers were "pointing" to something other than the DC, then you probably experienced slow connections, dropped mappings and dropped GP. If you are running Windows XP in a domain, it has to point at the domain controller.
Does this answer any of your questions?
I guess I am foggy as to what you mean by "pointing."
Oops...got posts mixed up - I answered yours above
The DNS server that was "statically" assigned to each PC was wrong as soon as the PDC went down. Were they still set to DHCP, they would have been able to get the DNS records from another computer, but because of the static assignment they were lost at sea.
You said the DC went down "hard." Are you sure you even have dhcp installed and running with a viable scope?
I'd still really like to see the IP numbers of some of those "static" addresses, and know if the boxes are checked to obtain IP addresses automatically.
Unless the system was set up with statics originally, and the server has been rebuilt in such a way that they don't match, I can't see how a bunch of clients just switched to static. In fact, I don't think they did...?
Help us out here?
I know...alot of this is redundant, but I just want to make sure everyone gets the answers they're looking for
The XP boxes definately
became static somehow - I fixed a good number of them myself. Whether or not someone personally did it, a group policy did it, or the server crash did it (or some unknown quantity) I can't say. The DHCP scope and everything *should* be set up correctly (no problems as long as the server is online), but then again, I'm definately
not a server guru, much less a networking guru. I can try to answer specific questions, but (as can be seen from my above posts), I'm hardly an expert. I can catagorically say that *I* didn't change the computers from DHCP to Static Addresses, and I can say that when the server crashed it crashed - in the midst of a reboot it hung (as a result of the failed RAID) and could only be accessed in Recovery Mode, which apparently limits it's ability to do it's job (just repeating what I experienced). Our network guy isn't the smartest, but he knows a helluva lot more than I do so...well...is it correct? I haven't the foggiest...but it seems to be set up correctly from my limited experiences.
This is quite interesting on the fact that your DC had crashed and a secondary "server" was brought online. If this new server did not aquire the FSMO roles and the gobal catalogue from the your original DC and you did not mention that these roles were seized, the original domain is theoretically non existant. The workstations are logging in under cached creditentials.
This sounds like exactly what happened, despite not understanding some of what you're saying
I cannot see how the workstation IPs were set statically by themselves. There has to be some sort of intervention at the workstation. Even if the workstations use APIPA, if all the workstation are on the same network, no two computers would get the same address. When the computer decides to use APIPA, it will broadcast what IP it will use. If no other computer responds, then it will assign itself that address. However if the computer is using APIPA, it cannot communicate with other computers on other subnets. Therefore it would be unable to contact the DC.
Can you explain a bit more about APIPA? I've noticed that with the IP address leasing stuff, it seems that a computer is prone to getting the same IP address anyway (unless there are conflicts). If that's the case, and if this could cause a formerly DHCP setting to become static, this sounds like what may have happened. The vast majority of the computers did not seem to have problems until after they were rebooted, perhaps clearing out some of the cached files and being unable to contact the PDC? If they were somehow attempting to use their former IP addy, it makes sense that there wouldn't be a conflict.
I just don't know enough about all of this - please pardon my ignorance
I realize that on an odd problem like this y'all need more clarification, I just wish that I were more capable of expressing what happened in real terms instead of having to rely on my understanding of what's going on (hence the bastardized geek-speak