"Trying to finish up my review for Inside AD 2/E, really behind on that."
Boy, are you ever! :p Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 07, 2004 10:19 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Lessons Learned]: Schema Mismatch promoting firs t K3 DC to GC in production forest... Several new experiences. Guido Guido Guido.... You insult me man... Of course I knew my replication was working in 2K. Both because it is monitored with custom joe scripts and we build DCs/GCs on a regular basis. Also we have a couple of thousand password changes a day and if every one had to be forwarded to the PDC my PDC would be falling over. We would use MOM but our company seems to think Tivoli is the way to go... I am not so sure, it seems they are really good at generating reports of which version of Tivoli is running but I can't see any other value. Of course the version of Tivoli running is exciting and important stuff... But... Well you know... I would kind of like to know about my Servers, not Tivoli. Does anyone have any good Tivoli stories? I haven't encountered anyone but IBM people and quite frankly, my opinion of IBM in the last year has gone from Ok to they positively suck and really have no understanding of Windows or what it takes to run an Enterprise... Check out their RSA solution, they need to go RAID Dell and hire away the DRAC guys. The Dell DRAC has the RSA beat by several years at least. Anyway, the issue according to the PSS guys was a new duplicate checking capability and this bad data was firing that functionality off... They didn't go into it any further than that. I.E. The 2K machines said, ok, you want me to replicate garbage, I have no problem with that. Whereas K3 said, NFW.... Unfortunately they said NFW and then told me a story about mice in south of France for the error message versus you have bad data. BTW, I will get to the other posts hopefully within the week, I have been hitting these one off (look at the last 5 posts) and see I have about 300 messages to read. Trying to finish up my review for Inside AD 2/E, really behind on that. Also I have to check out something for one of the Vendors that looks really cool that I asked for a long time ago. joe ------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Sunday, March 07, 2004 1:04 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Lessons Learned]: Schema Mismatch promoting firs t K3 DC to GC in production forest... Several new experiences. thanks Joe for the heads up - haven't had this one myself, however, I wonder what you're using to day to monitor replication of your AD? I suspect you'd have had similar replication issues with the european partition all along - no? Or was the "bad data on a multivalued attribute of a printer object" which was preventing the replication during the new 2003 GC promotion somehow known to all the other European DCs and GCs in your forest, prior to trying to promote that new DC to a GC? Could also be, that 2000 was less fussy about this bad data and now with some additional checks done on 2003 DCs, they don't replicate this data. I know for sure that this was the case during our implementation of 2k3 during the JDP over a year ago, but it was related to Foreign Princials Objects (FPO) that didn't have GUIDs, which were replicating fine between 2000 DCs, but not to 2003 DCs. Basically, the 2000 DCs were too stupid to notice that there is a problem with the corrupt FPOs and just ignored them. 2003 with the new added functionality around Single Instance Store for ACE etc. required to perform more checks on the data though. However, our problem was fixed in the RTM code of 2003 - but I wonder if you've hit something similar or if your problem also existed in 2000 and could have been seen prior to doing the 2003 forest/domain prep and introducing any new 2003 DCs? Would be good to know... /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Samstag, 6. M�rz 2004 19:39 To: [EMAIL PROTECTED] Subject: [ActiveDir] [Lessons Learned]: Schema Mismatch promoting first K3 DC to GC in production forest... Several new experiences. I wanted to document some stuff I learned this week. We finally have a K3 load with all of the stuff the company wants in it and tested, etc so we started deploying some K3 domain controllers. I tested this all out in our Exchange lab of course and it all worked well, in fact K3 DCs running in Virtual Server partitions were responding to queries faster than 2K DC running on physical hardware. It was nice. Note that I asked PSS first for a list of issues that could be encountered with K3 domain controllers with E2K. Still haven't gotten a response but on my own found that you can't increase your functionality mode as LVR will break the RUS and the ADC. The ADC won't be an issue shortly but the RUS obviously will be. The RUS has to be put on an E2K3 machine. There are KB articles for that. So anyway, my promotion of the DCs into production goes very well with very quick promotions. My DIT files shrank up nicely as predicted. I started one of the DCs on the road to becoming a full fledged GC and it got through all partitions but my european partition, it stopped dead there and started exclaiming SCHEMA MISMATCH!!! I being who I am thought several choice cuss words at first and then thought, could it be? No. But could it? No. Well... No. Decided I should contact MS but thought, well I better PROVE there isn't a schema mismatch first before I tell them there isn't or else they are just going to ask me to prove it or go off and try to do it themselves. So I dump the schemas from the source and destination and do a windiff... Wham. Mismatches all over. Oh... Objects in different orders, attributes in different orders, whenchanged different, etc... Ok so I write a perl script to parse the schema text file dumps and then normalize the info so I can do a windiff. All done, beauty, Schema's are identical. I will post that script or a link to it on the joeware site within the next few days or so as I figure others may find it useful as well. I will clean it up and I also want to make it handle doing easy compares between forests. Also checked the operations done for the forest/domain to make sure everything is correct. Had 53 ops done on some Domains, 50 done on others. Kind of scary. To cut to the chase on that one, seems that depending on the hotfixes on your machine, you can have different ops done to correct things. This isn't documented in KB309628. Also when I moved PDC an additional GUID popped up in the domain ops that the article says should be in the forest ops. I will put everything together and send one note to MS on those doc issues. So I gather all of the data, send it off to MS. We work through it turning up diagnostics, etc and in the end the issue becomes some bad data on a multivalued attribute of a printer object was preventing the replication from occurring. Somehow some bad binary garbage data got into the unicode string attribute and AD was flagging it as a Schema Mismatch error... The object was being flagged in the event log with a message of unable to replicate due to schema mismatch. Now this isn't a happy making thing from several standpoints. 1. Horrible error message. 2. If rules are going to be enforced that could prevent AD from replicating because of one bad field, we should have a tool available that can read through a partition and verify every attribute and object for correctness so if we run into an issue, we can verify the state of the directory. Actually this second one I think needs to be done for Exchange too. You can run it against a forest, a domain, or a user to verify that the data is valid for Exchange. We have had several issues where bad data made it into an Exchange attribute and it caused Exchange to have a heartattack. For instance we once had X400:X400:<x400 address> in our proxy address attributes due to a bug in an MCS script and how the ADC moved things around. No one knew it for quite a while and people were looking at the attributes of the user objects regularly. Being able to verify the data would have helped. MS indicated there are some (or a) fix in SP1 that will help a little with this one. Oh my production DIT files for GCs shrank from just under 8GB to about 4.5GB. Anyway, hopefully this is helpful to others out there in case they run into similar things. ------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
