The error “The length of the property is too long. The maximum length is 2 and the length of the value provided is n” is encountered when performing an action on an Active Directory user object within the Exchange Management Shell.
Check to see if you have passed an invalid value to one of the affected users’ Active Directory account. In my scenario, the problem was that I passed the ‘–country’ attribute the value “USA” not knowing that I was supposed to pass it a two character ISO 3166 country code.
After creating a user using PowerShell’s new-aduser cmdlet, I then used enable-mailbox and received the following error:
“The length of the property is too long. The maximum length is 2 and the length of the value provided is 3.”
On a hunch, I tried to use get-user to retrieve information about the user object. I received a very similar error: “The object [username] has been corrupted, and it’s in an inconsistent state. The following validation errors happened: WARNING: The length of the property is too long. The maximum length is 2 and the length of the value provided is 3.”
I then tried the PowerShell cmdlet get-aduser (admittedly by accident, I seem to get the two cmdlets get-user and get-aduser mixed up in my mind) and the properties of the user were returned without error. That struck me as interesting, but I wasn’t sure what that information was telling me.
I created a fresh user with the bare minimum of information through Active Directory Users and Computer and then ran enable-mailbox against that user. It worked perfectly.
I then tried ‘get-user *’ and saw these interesting results:
Something definitely went awry with the creation of that user from my new-aduser cmdlet. I went to the cmdlet and perused it, nothing jumped out at me. I started a new-aduser cmdlet from scratch and kept adding new users, gradually adding more and more switches and checking ‘get-user *’ to see when the user became corrupt.
I narrowed the problem down to the –country switch. I was giving country the value of “USA”. Upon further investigation, I realized that I misunderstood the usage of that switch. The real usage of the –country switch is that it “Specifies the country or region code for the user’s language of choice”. It apparently uses the ISO-3166 two character country code convention.
Strange that there’s no error checking to see if the input is valid. To my discredit, I should have first simply looked for a three character value in my new-aduser script as per the warning in the original error message. Had I done that, the ‘–country’ switch would have stood out and I could have fixed the cmdlet sooner.