Re: Question on Active Directory Schema Expansion



Yep I understand the reluctance of large companies, especially financials. All of my experience in the last 10 years has been in Fortune 50 or bigger, primarily Fortune 5 (I'm in southeast Michigan so I will let you guess several of the Fortune 5 I have done a lot of work for) all of which tend to have banking or trading divisions. Now I am out of ops and doing consulting for one of the big service companies but still working on Fortune 50 type clients usually trying to clean up the directory or figure out what is wrong with the Exchange/AD interfaces.

It tends to be good to keep the environments as simple as possible so that applications from vendors can easily work without much modification and so that the masses of internal developers around the world for the companies don't all have to be taught the special ways to do it inside of the orgs so they can easily take any class anywhere to get basic AD knowledge and apply it. They (the vendor apps and internal developers) will be expecting to be using user and contact and computer and OU and inetorgperson objects, especially for creations.

Any schema changes need to be made in the lab and thoroughly tested there. The lab should consist of multiple DCs and replication of the changes should be checked carefully as some problems become more obvious on replication. Prior to doing an actual live production forest update of a schema I tend to recommend sucking off the live production domains onto DCs and stick them in a segregated room cut off from the rest of the network and apply the changes there and see how they impact the production schema (because you never truly know). Once that is known to be good, then you follow the same procedure you used in test for updating the schema in production and things should go very well. Exceptions that will obviously be different in the real world is convergence time and if you have are doing PAS updates in a 2K environment you will have full replication for the GCs (which you usually can't mirror in test unless you have a giant test environment) and when you have index builds which can slow things down a little as well. I recall the first schema update we did for one of the Fortune 5 companies that MS told us would be done in about 90 minutes because that is what it took in the lab they mocked up for it... It really took around 18 hours. We smacked out onsite MS folks around quite a bit for that one.

Further, people should be checking the OIDs of adds they are making to the schema as well as checking for registered prefix names and registed linkids if any of the attributes being added are linked (preferably if using linked attribuets and the forest is 2K3 or better they are using autolinking and you don't have to worry about linkids).

Schema updates are generally safe. They are unsafe when people are being foolhardy and not up to speed with what they are messing with or the vendors from whom they are taking schema changes from aren't up to speed.

   joe


-- Joe Richards Microsoft MVP Windows Server Directory Services www.joeware.net


Ryan Hanisco wrote:
Hi Joe,

I find it a lot safer to make a derivative of Users to something like Employees and then make changes to the derivative. At the very least, it may be a good way to test extensions before all objects are modified.

You are right in that there aren't usually problems with this. Its just that I work in banking and Fortune 500 clients and they have surprisingly little sense of humor for problems, so it is best to be 100% sure of something before hitting production. Also, given the fact that the target audience is people who are learning about schema extensions or doing them for the first time, I wouldn't want to encourage extension of live objects if the alternative isn't specifically difficult.

I hope that makes a bit of sense and better frames that response. You'll find support for that position in both the WROX and Microsoft ADSI books, although common practice may have changed in the last few years.


.



Relevant Pages

  • Re: Move sharepoint to another server
    ... test environment's schema that aren't in your production's schema. ... customization in your production environment. ... > sharepoint portal server 2003 in my test server, now i want to move all ... Please upgrade the database ...
    (microsoft.public.sharepoint.portalserver)
  • Re: refreshing AD in testlab environment
    ... If you have two separate forests you can't magically bring across schema ... want to bring the testlab up to production leve. ... service accounts we use in production are different than the testlab. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Test Environment - How?
    ... I need the schema to come across (actually, if I could get the schema ... production, but I only want 2-3 in test, so I assume I don't want ... In addition to what Simon already suggested, you could try and test your Domain Controller backups by restoring the Active Directory Backups on the test environment machines. ...
    (microsoft.public.windows.server.active_directory)
  • db synchronization
    ... - compare 2 db schemas and update the production schema from the DEV schema. ... Only the schema, not the DATAS!! ... - you add a field within a table within your DEV environment -> it creates ...
    (comp.lang.php)
  • Re: what is the duration of forestprep in an existing exchange organization?
    ... test system, I think I can do it without loosing a weekend;-)) ... > Forestprep is updating the schema on the schema master. ... > environment has similar hardware to production then assume the same amount ... Exchange not be affected when Forestprep is being ...
    (microsoft.public.exchange.setup)