What a complete waste it became. The active directory was so thrashed that there was no way to recover it and make things useful.
That said, I am gong to put backups and secondary domain controllers on hold for a while until I've done some more self-educating on the subject.
The new network is in place however, and humming along quite well. There was a small glitch in getting the 98 machines printing again (had to add their computer name and users to the AD store) but that is now resolved. I ended up reinstalling the 98dsclient but I'm not sure if that was necessary. They don't login to the network.
One of the schools I'm supporting I hope will decide it's worth their money to invest in a backup solution aside from ntbackup. Basically with external drives on the cheap these days and the school's use of multimedia, using ntbackup to backup to DVDs each week is a bit tedious. More on that later and the solution that gets put in. I don't want to turn this blog into a bitch session (yet anyways).
Tuesday, October 18, 2005
MDaemon and Palm Synching with Outlook
Over the past six months one of the networks I support utilizes MDaemon as a groupware solution which works quite well. For our small organization it scales quite fine (just under 100 users). The only problem has been synching between a palm Tungsten T2 and Outlook.
At the time of this writing, the latest software for all is being used. I can't recall the palm software. MDaemon 8.1.3 and Connector 2.0.4 both of which run pretty smooth. There is one central shared calendar that is used as a "diary" for the entire school day. These events/entries are set to be editable by the owner, and two office administrators. Somewhere along the line, the synching of the palm seemed to be causing the wiping of any entered data. The first thought may be "Ah HA!, Your configuration is set to have the palm over-ride any settings!" but this is not the case. In fact, there doesn't seem to be any case for it. Very difficult to explain. The only thought I have is that the particular laptop these synchs were coming from ended up being on a computer in an old domain, and the mail server is in a new domain (with the same name).
Personally, I don't see how it could be anymore than operator error as there is nothing in the logs to suggest otherwise.
Tuesday, October 04, 2005
Active Directory and Backups
Whenever you develop a disaster recovery plan, make SURE you keep 3 backups especially if you are not experienced with developing (not maintaining) an enterprise-level backup system. I got bit by this in the past week. It has been experience well earned but at a price.
The main computer network I support has no test network. Nor do I have one (yet) at home. I consider this to be extremely important to have through the rest of my career. So soon as I get the chance, I'm going in the classified and getting three cheapy pIII boxes. That will give me the chance to get the majority effects of Active Directory replication I need as I shovel through my book kit
What happened is I have a two-server (and our web server linux box) domain setup. I have been performing disaster recovery/backup testing to ensure we don't go out of service because of a duff hard drive (which are now mirrored). The network is native 2000 domain, but there are still "main controller" roles filled by the first controller. I brought that controller offline while I pulled a different box and hardware up with the backup.
One of the mistakes I made was that I joined the domain and then performed a restore. Don't do this. Boot directly into Active directory restore mode and nowhere else. At this point I realized that things were not working as they should. The machine name was there and working BUT nothing was accessable from an Active Directory perspective (Roaming Profiles). Nor did the antivirus server software want to start its MS SQL engine, that I haven't spent enough time to figure out.
At this point after doing some digging and realized removing the master DC computer from the domain may get things going. I did not want to do this with a semi-functioning backup, so at this point I brought backup offline. When bringing the original master DC back online, the exact same problem for logins arose. The antivirus was fine, the DNS was resolving, and DHCP after a reauthorization was back in action. I removed the computer object from the active directory store and created a new one, gave it the same permissions, and voila, everything from userland is fully functional.
The problem is Active Directory. It is unhealthy at the moment. From box 1 (the master dc) I can no longer manage AD, I can manage box 2 AD however. A message appears about switching from domain . to domain contoso.com which then allows me to manipulate the AD from box 2. From box 2 I can manipulate both domain controllers.
Now in a real-world disaster recovery, I would have forced box 2 to become the master. Doing that though, means that box 1 may never be brought back into the network. That is not what I want to do because I was mearly "testing" disaster recovery. In the future, the proper steps to follow in order to test complete hardware failure recovery are to the best of my knowledge are here:
Some of the other nice links I have come across here, and here
At this point I will be seeking either help from MS or forums to get my AD back up to snuff.
It's all a work in progress...
What I've figured out I can do is because my most recent (only backup) of two weeks ago for our primary DC also holds a full backup of our secondary DC, I can perform a non-authoritive restore of the system state for each DC. Then, hopefully, that will fix the AD store. I am going to perform that this evening and post my results afterwards.
The main computer network I support has no test network. Nor do I have one (yet) at home. I consider this to be extremely important to have through the rest of my career. So soon as I get the chance, I'm going in the classified and getting three cheapy pIII boxes. That will give me the chance to get the majority effects of Active Directory replication I need as I shovel through my book kit
What happened is I have a two-server (and our web server linux box) domain setup. I have been performing disaster recovery/backup testing to ensure we don't go out of service because of a duff hard drive (which are now mirrored). The network is native 2000 domain, but there are still "main controller" roles filled by the first controller. I brought that controller offline while I pulled a different box and hardware up with the backup.
One of the mistakes I made was that I joined the domain and then performed a restore. Don't do this. Boot directly into Active directory restore mode and nowhere else. At this point I realized that things were not working as they should. The machine name was there and working BUT nothing was accessable from an Active Directory perspective (Roaming Profiles). Nor did the antivirus server software want to start its MS SQL engine, that I haven't spent enough time to figure out.
At this point after doing some digging and realized removing the master DC computer from the domain may get things going. I did not want to do this with a semi-functioning backup, so at this point I brought backup offline. When bringing the original master DC back online, the exact same problem for logins arose. The antivirus was fine, the DNS was resolving, and DHCP after a reauthorization was back in action. I removed the computer object from the active directory store and created a new one, gave it the same permissions, and voila, everything from userland is fully functional.
The problem is Active Directory. It is unhealthy at the moment. From box 1 (the master dc) I can no longer manage AD, I can manage box 2 AD however. A message appears about switching from domain . to domain contoso.com which then allows me to manipulate the AD from box 2. From box 2 I can manipulate both domain controllers.
Now in a real-world disaster recovery, I would have forced box 2 to become the master. Doing that though, means that box 1 may never be brought back into the network. That is not what I want to do because I was mearly "testing" disaster recovery. In the future, the proper steps to follow in order to test complete hardware failure recovery are to the best of my knowledge are here:
Some of the other nice links I have come across here, and here
At this point I will be seeking either help from MS or forums to get my AD back up to snuff.
It's all a work in progress...
What I've figured out I can do is because my most recent (only backup) of two weeks ago for our primary DC also holds a full backup of our secondary DC, I can perform a non-authoritive restore of the system state for each DC. Then, hopefully, that will fix the AD store. I am going to perform that this evening and post my results afterwards.
Subscribe to:
Posts (Atom)