Change mailbox language #Outlook #Exchange

 Exchange online had a bug for a couple of weeks, that many of our shared mailboxes came up english, despite that clients outlook is french, our lighthouse is french, the windows and local settings, server settings are all french. 

Probably even more mailboxes than the 5 we were treating, just users speaking proper English did not complain. We changed in many places the language, but it id not always or never get changed on client side. A weird behaviour from windows, that doing the same action over and over, back and forth can result in success. That is not true to life, as doing the same stuff over and over again, will have the exact same result.

So what you can do is run some commands in your WinKEY+Run window. Often outlook is so messed up, that you might want to run all of these. Some users, do not restart their old windows 10 laptop for 30days plus and they complain, outlook, onedrive, sharepoint, word and excel, nothing work. So yes, you might need to run all of these, to reset outlook and then, you can run the language changing powershell command. 

• outlook.exe /resetfolders
• outlook.exe /resetfoldernames
• outlook.exe /resetnavpane
• outlook.exe /cleanviews
• outlook.exe /cleansharing
• outlook.exe /manageprofiles
• outlook.exe /safe
• outlook.exe /resetaddins
• outlook.exe /cleanpst
• outlook.exe /cleansniff
• outlook.exe /cleantaskbar
• outlook.exe /rebuildsearch

    

You can go to new outlook and tick this box:

 

 You can try these powershell commands that most likely will work, after connecting to exchange online as admin of course:
So, it is my fault, as I was looking for outlook mailbox language everywhere. Including chatgpt and copilot too. One argument was always missing from my commands:

-LocalizeDefaultFolderName

I should have looked for outlook folder language or mailbox folder language. This is why when using chatgpt or copilot, you should always prompt full and precise information !

Powershell command:

Set-MailboxRegionalConfiguration -Identity user@domain.com -Language fr-FR -TimeZone "Romance Standard Time" -LocalizeDefaultFolderName

This is the command we started using the reset the language and it works like charm. There was one nasty folder that did not want to change and we used this command:

Set-MailboxRegionalConfiguration -Id jdupont -LocalizeDefaultFolderName:$true -Language fr-FR -DateFormat dd/MM/yyyy


The main difference is the $true at the end of -LocalizeDefaultFolderName.

Here you go, here is how you change folder language in outlook.  

  

Windows EFS encryption - Why ?

 

This is a very advanced windows feature, that should be used with very careful consideration. If it was me, in a corporate environment I would definitely disable this option.

So if a user forgot the encryption key, specific windows features should be enabled in order to recover the files. Like admin recovery, or user backup key recovery, so with the help of his own session password he might be able to recover the files. If you chose to remove encryption from the user session, then often only the certificate gets removed, so nobody ever again can recover the files.  

 Disable it with GPO:

 

Serious Issue 

Why would this be problematic and when would this become a mess ? Here is a great example: A user encrypts a distant 'share folder'. He gives the folder password to 4 other users. Her encryption takes a long time to pass down, other users can still access the folder.

Now she calls the admin centre, that what she wants is special permissions for this specific user folder, files and subfolders. In a giant environment, I would not recommend breaking folder rights inheritance, but in small infrastructures, I did test with even triple inheritance breaking and it works ! In our case it is a 3rd level folder, so I simply broke inheritance, added the created user group, added the 4 users into the group, set rights to RWE. 
It worked, extremely bizarrely, for about 2hours. Then the user who encrypted the folder called me, that her colleagues cannot access the folder any-more.  1hour later she calls me again, the she cannot access the folder any more either. We could see from any session, even on the file server, those small yellow padlocks appearing on all files. 

She never mentioned that she encrypted the files on the first place. So, if she says this first, we simply decrypt them and off you go. But once, you changed, not only rights but inheritance on this shared folder, after encryption, nobody ever can touch those files. You can put it back to original rights state, nothing will happen. No more access.
We had VEEAM and windows history backup. "User Rights Backup" only of VEEAM doesn't work in this situations and comes back with an error. Windows history shows padlocked files till the day of the back up and even if backed up to the day with padlocks on, you still cannot decrypt the files, despite the original user rights. 

 If you don't have the knowledge of who did what, you can run these commands:

attrib "C:\path\to\folder"

cipher /c "C:\path\to\folder"

Right click on folder -> Properties -> General Tab -> Advanced -> Details 
You can see now who encrypted the folder. This is important for your documentation as to see, that it is not you messed up.  

 

Padlock on top right is encryption issue. Padlock on bottom left, is rights issue. Like classic windows, sharepoint or one drive issue. Padlock on the Status info, is share lock, sync lock or other issue. 

In this case, there is no point wasting time. She just confirmed her date of encryption, we recovered the whole folder. It was possible either with windows history or with VEEAM. 

 

I have found one website that states recovery possibilities:
https://tinyapps.org/docs/decrypt-efs-without-cert-backup.html