Ugh. Ok thanks Eric, I will sent it to the load integrators and have them wrap it up for us. :o)
------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Monday, March 08, 2004 11:30 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Lessons Learned]: Schema Mismatch promoting firs t K3 DC to GC in production forest... Several new experiences. It's been a while, but I think nTSecurityDescriptor. I'd need to look back at the code change to know for sure though, but I'm like 95% sure of that. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, March 08, 2004 6:31 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Lessons Learned]: Schema Mismatch promoting firs t K3 DC to GC in production forest... Several new experiences. Is the issue on the handling of the ntsecuritydescriptor or the msexchsecuritydescriptor? ------------- http://www.joeware.net (download joeware) http://www.cafeshops.com/joewarenet (wear joeware) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Monday, March 08, 2004 2:21 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Lessons Learned]: Schema Mismatch promoting firs t K3 DC to GC in production forest... Several new experiences. Eric? Eric? Bueller? Bueller? I can probably speak to it to some degree (although the details are fuzzy....it's been a while since I saw this one....one of my office neighbors worked it) Conceptually, Joe, this is similar to what you hit. A condition of some sort that makes the DSA complain loudly and subsequently cause a replication issue (potentially, depending upon the condition we're talking about). The bad acl in question causes 1699's and 1173's. So the bad acl shouldn't be there, sure, but the DSA should also be robust enough to handle it. The code change in question makes that a reality. ~Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT) Sent: Monday, March 08, 2004 9:25 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Lessons Learned]: Schema Mismatch promoting firs t K3 DC to GC in production forest... Several new experiences. Not a clue Joe, other than what is implied. Todd -----Original Message----- From: joe [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 10:06 AM To: [EMAIL PROTECTED] Subject: FW: [ActiveDir] [Lessons Learned]: Schema Mismatch promoting firs t K3 DC to GC in production forest... Several new experiences. Ugh. Thanks Todd. Love the LSASS leak... And yet another FRS fix that will make FRS work perfectly. :oP I would like to understand the first one better... The KB article is kind of hokey in its description.... Do you know any more? Eric? Specifically "this problem occurs if the msExchSecurityDescriptor property has been written to the object instead of to the NTSecurityDescriptor (NTDS) property."... What in the world does that mean? 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 Myrick, Todd (NIH/CIT) Sent: Monday, March 08, 2004 9:21 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, Below are the pre SP1 AD hotfixes we are testing with our deployment. These are only the ones for DC's... we also apply about 15 pre SP1 hotfixes that deal with security issues as well. E2K3 and 2K GC's Upgraded to 2K3GC's http://support.microsoft.com/default.aspx?scid=kb;EN-US;832851 DNS http://support.microsoft.com/?kbid=830381 http://support.microsoft.com/?kbid=830905 FRS http://support.microsoft.com/?kbid=823230 VSS http://support.microsoft.com/?kbid=826936 DC/GC http://support.microsoft.com/?kbid=824139 http://support.microsoft.com/?kbid=829993 Windows 2000 Post SP4 Hotfix for Directory Access events not reporting. http://support.microsoft.com/default.aspx?scid=kb;en-us;833873&Product=win20 00 Todd -----Original Message----- From: GRILLENMEIER,GUIDO (HP-Germany,ex1) [mailto:[EMAIL PROTECTED] 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/ 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/ 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/