For those of you planning to extend your AD DS or AD LDS schema, you will need to find a unique object identifier (OID) for each new schema class and attribute. The process by which you can acquire the OIDs is described by Microsoft here:
In summary, Microsoft suggests two methods for obtaining an OID:
1. Contact the International Standards Organisation (ISO) Name Registration Authority specific to your country; or
2. Use the oidgen.vbs script provided by Microsoft. This method generates a random GUID and hangs it off an existing OID owned by Microsoft.
Another option not referred to by Microsoft is to contact the Internet Assigned Numbers Authority (IANA) and request a Private Enterprise Number (PEN). The process is free an you will be able to acquire your very own root OID within 30 days of submitting a request.
Obviously, the scripted method is the quickest and simplest. I guess the only downside is that there is a (very) remote possibility that the same OID can be generated twice. Hidden away on the Q&A page of the oidgen.vbs script is a really nice little Powershell script that does the equivalent. The script is written by Jiri Formacek of Microsoft and I take absolutely no credit for it. 🙂
I’ve seen a number of instances where people advise only to use the script in lab environments. Personally, I can’t help thinking that this is being overly cautious. Here are two examples of the OID generated by the script:
Microsoft’s root OID is shown in bold. As you can see the remaining portion is fairly long. I’m no mathematician, but what are the chances of the same OID being generated twice? I guess it depends a little on the algorithm used to generated the new GUID. Even if that scenario were to occur, what are the chances of the same schema extensions using the identical OID being used in more than one organisation?
Your approach will depend on your attitude to risk, but if you are not a software vendor then I would think it fairly safe to use the scripted approach for your custom extensions.