Active Directory stores most of the commonly-used attributes internally in a string syntax, including most naming and address attributes as well as many organizational attributes. The process used to programatically update string attributes is usually very straightforward and merely requires you update the attribute value and then commit the changes to the directory.

Ah, but exceptions seem to always come up even with straightforward processes. In many cases, we see this happen when updating the country attribute in Active Directory. At first glance this attribute seems just like the other address attributes in AD: streetAddress, l, st, postalCode, etc. When you look at the country for a user account in Active Directory Users and Computers (ADUC), you see the nice friendly name for the country. Updating this value merely requires you to select another country and update the changes.

But try updating the country attribute programatically in Active Directory. Looking through the raw attributes for a user account using a tool like ADSI Edit or Active Directory Explorer shows several promising candidate attributes to use to update the country data. As you dive deeper, though, you’ll notice that there are actually three different country-related attributes. What gives?

At the end of the day, to update a country value in Active Directory requires you to update three different attributes at the same time: the countryCode, c and co attributes. Better yet, you must update two of the values, countryCode and c, using the appropriate integral and string ISO 3166 country code values or the update will fail.

• countryCode (Country-Code): ISO-3166 Integer value
• c (Country-Name): ISO-3166 2-digit string value
• co (Text-Country): Open string value