A new employee started at the company I work for. He speaks German, and our environment is set up in Dutch.
After creating and setting up his account, we noticed his mailbox remained in Dutch, even though we set the language everywhere we could in the GUI and AD to German (de-DE). This included the changes I wrote about in this post: https://www.mattiasvdl.be/display-language-in-hybrid-environment/
Outlook – Foldernames in Dutch while everything else in German
As everything is in German (web browser, Windows, Microsoft 365, …) except for his mailbox which was displayed in Dutch, I decided to user the Exchange Powershell module in order to check if I can find any language or regional settings which might be hidden in the UI.
And what do you know! That’s exactly what I found. A hidden setting in Exchange online which specifies the language of the mailbox.
Powershell ExchangeOnline module – MailboxRegionalConfiguration shows the hidden language setting
After changing the language here, you can force the folder names to be reset by starting Outlook using the “/resetfoldernames” argument.
Outlook.exe – reset foldernames
The foldernames should now be displayed in the language you specified using Powershell.
Below you can find the code I used:
# Install the ExchangeOnline module incase you haven't got the module yet:
Import-Module ExchangeOnlineManagement
# Connect to ExchangeOnline:
Connect-ExchangeOnline -UserPrincipalName %YourAdminUPN%
# Check what language is currently set for the user:
Get-MailboxRegionalConfiguration -Identity %UPNOfTheUserMailbox%
# Change the language for this mailbox:
Set-MailboxRegionalConfiguration -Identity %UPNOfTheUserMailbox% -Language %LanguageCode%
# Disconnect from ExchangeOnline:
Disconnect-ExchangeOnline
By default, most users have the Office Display Language set to their native language. When sending out a Teams meeting request in Outlook, you will notice this meeting request will use the Office Display Language.
Teams meeting request – Dutch
If you prefer the meeting request to be sent out in a different language, you’ll have to adjust your Office Display Language to the language you prefer for the meeting requests.
Outlook – Change Office display language
After changing the Office display language, restart Microsoft Outlook and restart Outlook.
Note: After restarting Outlook, you’ll notice the first Teams meeting invite you try to create will still be in the language that was previously set. Just close this meeting request and create a new one. This one should be in your new Office display language.
Teams meeting request – English
Using a policy to set default meeting request language
In an Organisation environment, it might be more interesting if this can be managed by the system administrators.
It is possible to pin the language used for the meeting invites down by using a Teams Policy. The option which needs to be set is sadly enough not visible in the Teams Admin Center, so we’ll have to adjust this setting through Powershell. For this we’ll need to use the MicrosoftTeams Module.
Below you’ll find the PowerShell commands which I used to add the Teams Meeting invite in 2 languages when you click on the Teams Meeting button in Outlook.
Outlook – Example 2 languages in meeting request
As this is a policy change, you will need to have a policy group to which you want to assign it. I’ve created a new Meeting Policy (MattiasVdlTestGroup) just for testing functionality:
In case you haven’t installed the MicrosoftTeams module yet in PowerShell, execute the following code:
When you’ve got the module installed, connect to your tenant using the command:
Connect-MicrosoftTeams
A pop-up window will appear in which you will have to select the account which has Teams admin rights.
First I want to check to make sure the custom Meeting Policy I created can be found and what settings can be set for it. For this I used the following command:
Get-CsTeamsMeetingPolicy
This gave me this result:
Next we want to the languages for the meeting requests. In my case, I’ve set the language “en-GB” and “it-IT”. This is done with the following code:
A couple of months ago, I needed to create a lot of Win32 apps. As I knew these apps would have to be updated and repackaged quite a few times in the future, I decided it would be worth the effort to automate this process using a script.
The purpose of these apps was to create a shortcut under the Start Menu of the end user which points to a script placed under %PROGRAMDATA%. When executing this script, a check was done to see if the end user is working in the office or remote. If the end user works remotely, then the application is started in an RDS environment. Otherwise, the app gets started locally on his device.
This post is focussed on the deployment of Intune Win32 apps through the use of a Powershell script, and as such doesn’t contain the code I mentioned above.
PackageAndUploadIntuneWin32App.ps1 This Powershell script contains all of the code to generate the 3 needed Powershell scripts, package the application and upload it to Intune.
The 3 Powershell scripts which need to be generated: – App_MattiasVdl_Setup.ps1 This script is used to create the shortcut under the start menu, and copy the script, which is executed by the shortcut, to the correct location. – App_MattiasVdl.ps1 This is the script which gets executed when a user clicks on the shortcut which was created under the Start Menu. All logic which was in this script has been removed, and all it does now is display a message box. – App_MattiasVdl_Detection.ps1 This script is used by Intune to detect whether or not the application has been correctly installed on the device.
To start off with, a lot of variables are declared which are later used in the application.
We specify an array which contains the different types of scripts which need to be created.
The script makes use of “template” scripts, in which there are strings of text that get replace by the correct values. The location of these template scripts is defined in the variables.
We also specify in these variables what the name of the application needs to be, what icon to use and the log which should be used in Intune.
We use a foreach loop to generate the necessary scripts.
First we load the script into a variable, and save the output URL to a variable so we can use it later.
Next we modify the script which we loaded into a variable. We replace all instanced of the variables we placed in the template (using the “{}” as a way to easily be able to replace the strings without replacing things which shouldn’t be replaced.
Then the modified script gets saved to the output URL which we saved to a variable earlier.
The script copies the icon over from the original location to the folder which will be be packaged and uploaded to InTune.
All necessary preparations have now been done and we’re ready to package the application. This is done using the IntuneWinAppUtil.exe, which is also available on my Repository, but I recommend you download the latest version of this app from the original creator (microsoft/Microsoft-Win32-Content-Prep-Tool).
Now it’s time to upload the application to InTune. First we set some of the variables which will be used. Change the TenantID in line 106 “Connect-MSIntuneGraph” to your own TenantID.
In my example script I’m not setting any dependencies, supersedence or assignments. These can all be added automatically, but in my case, I prefer to manually check up on the applications which are uploaded and assign them to the relevant groups manually.
App_Link_Application_Setup.ps1
This script contains the base code, which is edited by the main script, and is used to install the application script and shortcuts on the end-user device.
Note: There are multiple ways of adding folders and files to your Start Menu. Only for 1 user: %APPDATA%\Microsoft\Windows\Start Menu\Programs For all users: %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs
Also keep in mind that the name of the shortcut can’t be the same of the name of the folder. If the name of the folder is identical to the name of the shortcut, then the folder will not be shown!
App_Link_Application.ps1
This is the script which will get executed when the end-user presses the shortcut which has been added in there Start Menu.
App_Link_Application_Detection.ps1
This is the detection script which reports back to Intune whether or not the applications has been installed correctly.
Note: In order for a detection script to work properly, it needs to both exit with code 0 AND write something to STDOUT
Some of the functions offered by PowerToys which could be usefull:
Always On Top
PowerToys – Always On Top
Allows you to force an application to always be shown in the foreground, even when the focus changes to another windows.
Color Picker
PowerToys – Color Picker
Tool which can be used to quickly figure out what color is used for a specific pixel on the screen.
FancyZones
This is a window manager which I personally use alot as I sometimes feel limited to the number of snap points which are available in Windows by default.
Image Resizer
PowerToys – Image Resizer
Useful tool to bulk resize images.
Mouse utilities
Find My MouseMouse HighlighterMouse Crosshairs
Find My Mouse: Press the left Ctrl key twice to set the focus on your mouse cursor. This can be usefull to quickly find your mouse back again when you are using multiple screens
Mouse Highlighter: When right clicking, a blue dot is shown where you click, and when left clicking, a yellow dot is shown. This can be very useful when you have to create video’s demonstrating how to do something. The colours can be customized in the application.
Mouse Crosshairs
Text Extractor
PowerToys – Text Extractor
Works like Snipping Tool, but copies the text out of the selected region using OCR and puts it on the clipboard.
In a cloud environment, you can change your display language on Microsoft 365 (https://www.office.com) when you click on the gear icon on the top right of the page, and then selecting “Change your language”.
Office.com – Change your language
For users in a Hybrid environment, the possibility to chose the display language is greyed out.
Office.com – Change display language greyed out
In order to change the Display language, the user needs to contact the administrator of his organisation, which can then change the language to the prefered language in Active Directory.
The administrator needs to change the attribute “preferredLanguage” to the prefered language code under the users properties (Attribute Editor), in Active Directory Users and Computers.
Active Directory Users and Computers – User properties – Attribute Editor
After setting this value to the prefered value, it will take some time before this value is synced to Azure Active Directory, and take effect for the user in Office.com.
To speed up this proces, you can trigger a Delta sync from the server which contains the “Azure AD Connect” application.
Open a elevated Powershell Prompt on that machine, and type in the following code:
Start-ADSyncSyncCycle -PolicyType Delta
PowerShell – ADSync
Once the sync is completed, you should see the same value as you set under “preferedLanguage” in the properties of the user in Active Directory, appear in the Azure Active Directory admin center in “Overview” – “Properties”:
Azure Active Directory admin center – Preferred language
Next time the user in question logs in on Office.com, the language should be changed to the set value.
After updating the user data of a big list of users in Active Directory, we noticed the Usage Location was not updated in Azure Active Directory. For this I created another script which goes over the same .csv file as the script did which updated the AD information.
I had to make a bulk update of data for a list of users, and instead of opening each user profile one by one and changing the values, I decided to write a script which could do this in bulk for me. It saved me a lot of time and avoided typing and other user errors. I only needed to make sure the input csv was set up correctly.
What?
I started of with an export of all necessary fields from the Active directory, made this a bit more readable for the people responsible for determining the data which needs to be updated, and provided the file to them for correction of the data. When I received the file back, I made sure all necessary data was filled in, generated the necessary codes for the countries, and generate the .csv file this script needs to make the updates.
This script loads in the .csv file and loops over all users in the file and updates the necessary fields.
More information
The titles in the .csv file are the names used in AD. You can look these up in the “Attribute Editor” tab.
For the Country details:
“c” = 2-character ISO-3166 country code (ex.: BE)
“co” = the name of the country as a text string (ex.: Belgium)
“countryCode” = the country code for the user’s language of choice (ex.: 56)
In this script I only changed a couple of fields, as more where not required in this case. I also just cleared some attributes, without replacing them. You should be able to edit the code based on this example in case you need to edit more attributes.
