Then consider trying this following command (all one line) and testing how everything works. If you find something bad that happens in Windows, let me know so I can feed that info back to the people who need to know.
adfind -schema -f objectcategory=attributeschema searchflags -adcsv | admod -unsafe searchflags::{{.:SET:512}} -cont
I have done this in a couple of forests now with no meltdowns but admittedly the level of testing I get to do on Longhorn right now is minimal at best. Most days I am happy to be working on Windows Server 2003 or better and thrilled to work on AD.
This will mark attributes to not be replicated to the RODCs. It won’t succeed in marking every attribute this way (unless you are sneaky about it) but in a default Longhorn Schema it will mark over 1000 attributes to be excluded.
Why should you do this?
The first reason is so if there is a problem with one or more of those attributes being marked that way, Microsoft can correct that prior to releasing the product to the street and hopefully prevent someone from having a problem.
The second reason and the reason that I initially thought of was so you can set up RODCs to have a very minimal attribute set replicated to them. The locations that RODCs are most likely going in to will be WAN sites and generally WAN sites have your worst network connectivity and no need for all of the data in the directory. Actually you usually just need the NOS attributes in the WAN site so you can log on. Having the ability to trim down the set of attributes replicated to those RODCs means less bandwidth and less churn in general since there are less attributes that you have to worry about being updated.
The third reason is to do something you may not normally do. People should play with their test labs and do things they wouldn’t normally do so they can learn what Windows does in those conditions. You may find bugs, you may learn something you wouldn’t know otherwise. You may remember something later that you see in production that reminds you of something you screwed up in the lab and figured out how to fix. A little secret here… A lot of folks are always asking how I got to learn so much about Windows. Some of it was picked while I did admin work. Some of it was picked up while I tried to answer questions for others who were having issues. A lot of it was picked up while reading the Platform SDK to figure out how to write programs to run on Windows to do various things (plus I just like to browse the SDK to find new things that MSFT hasn’t written tools/interfaces for or wrote tools/interfaces that didn’t expose all of the functionality). And finally a lot of it was picked up by doing absolutely insane things to my test lab and seeing how Windows handled it and if it was broken, trying to fix it again. Then if I figured out how to fix it I would purposely break it again just to make sure my methods for fixing it worked and try to better understand why it broke, when it could break like that on its own (or through someone’s stupidity) and better understand why the methods that fixed it worked and if there is anything else that might work. If you run some test machines and you just let it sit there idling in some standard config, that is fine if it is for testing things for your production environment, but if they are true R&D test whatever machines, beat them up. With the cost of virtualization so cheap now there really is no excuse to not have some beat up machines laying around that you can do insane things to and see how they react and what it takes for you to fix them again.
joe
