Forum Discussion
Fixing Azure AD user folders to avoid apostrophes and unicode characters
poreganis the solution - Beta: Use Unicode UTF-8 for worldwide language support - outlined here: https://learn.microsoft.com/en-us/outlook/troubleshoot/profiles-and-accounts/outlook-displays-error-message-on-first-start not an option?
BalazsOrban1 thanks for the suggestion. We're trying to go the opposite way, actually. But the fact that Outlook, the Most Important Program of an organization, has the same problem with the profile directories highlights the problem with how Azure AD works with existing software and is a very strong argument for having an adjustment knob at the AzureAD level.
We want Azure AD to fallback to use an ASCII version of the display name and strip apostrophes for profile folders to solve this problem for multiple applications rather than have each program need extensive updates. The real-world cases we're seeing break in Altair, Mathworks, and TI software are because of this oversight. A lot of these programs use some kind of a pipe or command line link between programs, and that's where the apostrophes (single quote) and Unicode characters are causing errant behavior.
If you're the user, you can fix an error in a local folder by renaming it, but you're powerless if it's your profile.
It also makes it challenging to work between Linux and Windows environments because we can't have matching usernames.
Personally I don't get why I have to choose between having functional software and having the apostrophe in the "From" field of my email address/SharePoint display name.
Hi poregan , sorry to revive the thread. But I want to ask, did you ever arrive at a satisfactory solution?
We are facing the same problem in my organization, and our work-around is to temporarily edit the displaynames before setting up devices, to avoid non-ASCII characters in the userpath folder.But from your post, I can see this issue has existed for much longer than I expected, and I'm shocked that it still persists.
I assume it should be relatively simple for Microsoft to give us an option in AzureAD to generate the userpath folder based on UPN or display name with ASCII-substitution.Hi AugustKV,
I'm sorry to say that we haven't yet received a satisfactory answer. We have a ticket in, and it's been bounced between Azure and Windows teams, maybe also Windows Server. I think that's the primary problem: it's a bug running across an organizational silo barrier.
On our associated support calls regarding the ticket, one of the Microsoft support team members (technically an external agency contracted to represent Microsoft) went so far as to imply that it was my fault for having an apostrophe in my (legal) name. He said that if I wanted to use Microsoft products successfully I needed to change it. I could never use my real name in SharePoint or email so long as my company used Azure AD. The support agents were unwilling to acknowledge it was an edge case in the software, unwilling to escalate the ticket to a product manager, and unable to tell me if a developer would ever see the issue. It left us unsatisfied with the entire experience. I've never felt more disrespected by a support agent. I assume they had to abide by a script where they cannot admit a defect in Microsoft products, so therefore the customer is always wrong.
This bug breaks Powershell, by the way, but oddly the git bash and Terminal apps handle it fine.
We're exploring an on prem AD solution now to fix this but it's an expensive step backwards with a lot of overhead and security implications that are the reasons we picked Azure in the first place. And early indications seem like it also may not work satisfactorily. Our workaround right now is having me use an entirely separate account to run simulation work using the affected software. Moving back and forth is a pain.
I agree with your fix assessment, and if we're wrong about it I hope a developer could chime into the thread to explain why.
It seems like it's around ten lines of code and an if statement for the Windows team and an extra database column for Azure to create a clean, lasting solution that supports people of all nationalities and name spelling, including extended ASCII and Unicode characters.
Related questions I've been wondering about is how these issues might affect non-Latin characters if Windows and Azure are localized in Japanese, Mandarin, Thai, or Korean characters and how using DisplayName for deployment deals with position suffixes common in larger organization accounts (often government or government adjacent).
