!!! Overview[1]
A [{$pagename}] or ([UUID]) is an [Unique Identifier] standard used in software construction and other systems standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE) and defined within [RFC 4122].

The intent of [{$pagename}]s is to enable distributed systems to uniquely identify information or [Entities] without significant central coordination. In this [context] the word unique should be taken to mean "practically unique" rather than "guaranteed unique". Since the identifiers have a finite size, it is possible for two differing items to share the same identifier.

The identifier size and generation process need to be selected so as to make this sufficiently improbable in practice. Anyone can create a [UUID] and use it to identify something with reasonable confidence that the same identifier will never be unintentionally created by anyone to identify something else. Information labeled with UUIDs can therefore be later combined into a single database without needing to resolve identifier (ID) conflicts.

!! Binary Encoding
A GUID can be stored as a 16-byte (128-bit) number.

%%information
[Microsoft] format differs from the [UUID] standard in the byte order of the first 3 fields.
%%

[Microsoft] defines a format which is split into four fields, defined as follows:
||Bits||Bytes||Name||Microsoft Endianness||Endianness [RFC 4122]
|32|4|Data1|Native|Big
|16|2|Data2|Native|Big
|16|2|Data3|Native|Big
|64|8|Data4|Big|Big

This endianness applies only to the way in which a GUID is stored, and not to the way in which it is represented in text. GUIDs and RFC 4122 UUIDs should be identical when displayed textually.

One to three of the most significant bits of the first byte in Data 4 define the type variant of the GUID:[3]
||Pattern||Description
|0xx|Network Computing System backward compatibility
|10x|Standard
|110|Microsoft Component Object Model backward compatibility; this includes the GUIDs for important interfaces like IUnknown and IDispatch
|111|Reserved for future use
For the "standard" variant, the most significant four bits of Data3 define the version number, and the algorithm used.[3]

!! Text encoding
A [GUID] is most commonly written in text as a sequence of hexadecimal digits separated into five groups, such as:
{{{
3F2504E0-4F89-41D3-9A0C-0305E82C3301
}}}

This text notation contains the following fields, separated by hyphens:

||Hex digits||Description
|8|Data1
|4|Data2
|4|Data3
|4|Initial two bytes from Data4
|12|Remaining six bytes from Data4
For the first three fields, the most significant digit is on the left. The last two fields are treated as eight separate bytes, each having their most significant digit on the left, and they follow each other from left to right. Note that the digit order of the fourth field may be unexpected, since it is treated differently from the other fields in the structure.
Often braces are added to enclose the above format, such as:
{{{
{3F2504E0-4F89-41D3-9A0C-0305E82C3301}
}}}
This is sometimes known as "registry format".

!! [LDAP Server Implementations] using [{$pagename}]
* [EntryUUID] - Uses the [RFC 4122] Standard.
* [GUID] - Used by [EDirectory]
* [ObjectGUID] - Used by [Microsoft Active Directory]

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }] 
----
* [#1] - [universally unique identifier|https://en.wikipedia.org/wiki/Universally_unique_identifier|target='_blank'] - based on information obtained 2014-08-07