GUID Endian Converter

What is a GUID

First lets check what Microsoft says about the GUID:

“GUIDs are the Microsoft implementation of the distributed computing environment (DCE) universally unique identifier (UUID)”

Well what is a UUID then? Lets check RFC4122:

This specification defines a Uniform Resource Name namespace for
UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally
Unique IDentifier). A UUID is 128 bits long, and can guarantee
uniqueness across space and time. UUIDs were originally used in the
Apollo Network Computing System and later in the Open Software
Foundation’s (OSF) Distributed Computing Environment (DCE), and then
in Microsoft Windows platforms.

So now we know that the GUID is a value which should be unique (there is not such thing as a guaranteed unique since there is no central authority). So lets check how the GUID is built and why this entry is needed.

Structure of a GUID

Lets look at a sample GUID ED7BA470-8E54-465E-825C-99712043E01C. Here there is a small difference between the UUID and the GUID specification, but it does not change anything. Both start using one 32bit Unsigned Integer followed by two 16bit Unsigned Integers. Then the UUID is specified as two 8bit Unsigned Integers followed by 6 bytes. Where as the GUID is specified as 8 bytes. But it does nothing to change the problem or the solution so lets leave it as 8 bytes.

The problem

RFC4122 specifies that the GUID must be precented as big endian but Intel processors are little endian. This is where the problem comes from. There are some applications that read the GUID in little endian format and store it as a string which does not do the little to big endian conversion by magic. In these cases you need to use a cmdlet as mine to convert between the endian formats.


What is Endianess. In simple terms its is in what order the numbers are stored. Just because a number shows away on the screen does not mean that the processor sees it that way. For simplicity lets take a 16bit Unsigned Integer to play with, I choose the 16 bit as it has 2 bytes in it.

Value Description
12345 Decimal value
3039 Hex value in big endian format
3930 Hex value in little endian format

So it seems that Windows reads integers bytewise from behind, so that is the reason why the 2xUnsigned Int 8 vs 2 bytes doesn’t matter. Since an 8 bit integer is stored in one byte there is no byte ordering at all. But for the 32bit and 16bit unsigned integers the order does matter.


Dell Software migration manager for AD by default stores the GUID in a little endian format in extentionattribute15 when migrating objects.
Some products use the GUID for permission. I know IBM uses it in some products.

The cmdlet

First just download the cmdlet from the Microsoft Technet Galleries. There is support for Get-Help. But its simple and I think there should be no problems. It supports both GUIDs supplied using parameters and the pipeline.

convert-virotguid example



  1. Jerry Gaber says

    I am using an application that uses the little endian format for LDAP authentication but if I use powershell to populate the field it populates it as big endian this causes the LPAD authentication to fail. I can use your function to get the little endian format for a single user and if I store that in the apps table for ActiveDirectoryIdentifier it works but I would have to manually replace each one. I am trying to automate the process but to do so I need at least one additional Active Directory attribute to match on. I can get a list of a group of little endian formatted guids but no way to match them to the correct record. could the Function be modified to output both formats i.e. 2 fields not just one ( little endian, big endian) then I would have a comparison field to use in an update statement.

Leave a Reply