LOL. Thanks Eric. If you want you can go look at the actual PSS case. It was handled by S. Linehan out of LC. Specific attribute was printMediaReady. I like him, he is pretty good. Though I shouldn't say that or he will go away like JD did.
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 Eric Fleischman Sent: Sunday, March 07, 2004 12:04 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] [Lessons Learned]: Schema Mismatch promoting firs t K3 DC to GC in production forest... Several new experiences. I can speak to the schema mismatch error. Strangeness. I've worked other issues like this one ('like' being defined as w2k03 dsa disliking something that w2k dsa was a-ok with and as a result causing a replication problem) but haven't encountered this one specifically. Any details you could provide me would be helpful Joe. I'll do some research offline. And I have the answer to your other question, just crafting a somewhat descriptive response now.....every time I write it somehow it just doesn't make sense (even to me). ~Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robbie Foust Sent: Sunday, March 07, 2004 10:42 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] [Lessons Learned]: Schema Mismatch promoting firs t K3 DC to GC in production forest... Several new experiences. Tivoli? Did someone say Tivoli? Yuck! I don't run Tivoli monitoring on my AD servers as I have avoided it like the plague, but we do have a Tivoli presence here, and I really really dislike it. I agree with your statement that IBM has no understanding of Windows. its like they get the product to compile, and then they're done. Right now I just use custom written scripts for monitoring, but have looked at MOM. Haven't made a decision on it yet though. Robbie Foust, IT Analyst Systems and Core Services Duke University joe wrote: > 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/ 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/
