Configuring Regional Settings and Windows locales with Group Policy

Configuring Regional Settings and Windows locales with Group Policy is about managing user location settings such as region, currency and time. A locale is a unique combination of language, country/region, and code page. Part of these settings are user-specific, others are system-specific (local machine) and thus apply to all logged-on users.

 

 

Table of Contents

Introduction

This article applies to all operating systems starting from Windows Server 2008/Windows 7 all the way up to the latest versions and builds (currently Windows 10 version 1809 and Windows Server 2019)!

I know, I know, this topic is a bit of a "golden oldie", but still very relevant today. In my lab environment, I recently found myself struggling with this old topic again. Once again I faced the problem of incorrect regional settings, incorrect time format, incorrect code page and incorrect time zone. And mind you, my lab environment exists of Windows 2016 servers only (OK, I have one 2012 R2 server). Having solved such issues before, I knew I could configure all settings centrally using Group Policy. This blog post is for all of you fellow administrators out there who struggle with the same issues.

I am sure that you are familiar with the Regional Settings Control Panel item. Before you continue with the various sections below, I would like to remind you of the fact that the tabs Formats and Location contain user-specific settings and that settings on the tab Administrative are system-specific.

These system-specific settings concern the international settings for the welcome screen and system accounts as well as the local system's code page for programs that do not support Unicode. For detailed information how to configure the code page please see the article Configuring the time zone and code page with Group Policy on this website.

The rest of this article deals with the user-specific settings (= the first two tabs) only.

Configuring Regional Settings and Windows locales with Group Policy - Regional Settings overview

One last thing. All configurations described in this article are stored in the Windows registry. If you are unsure of the exact value of a setting, for example concerning country codes, I recommend you to first configure the setting using the graphical interface. You than go to the registry and read the configured value, which you can than use in your script or Group Policy setting.

Quick list of the main registry values mentioned in this article

In case you are not in the mood for any blabla, I have listed all relevant registry keys and values in this section. If you know your way around Group Policy Preferences, you do not need to read further. Here it goes.

Regional settings:
Registry key: HKEY_CURRENT_USER\Control Panel\International
Registry value: multiple values in the aforementioned key
You can configure Regional Settings with the Regional Settings Group Policy Preference (User Configuration \ Preferences \ Control Panel Settings \ Regional Options).

24/12 hour clock and AM/PM time settings:
Registry key: HKEY_CURRENT_USER\Control Panel\International
Registry value: sShortTime (REG_SZ)
You can configure the time settings with the Regional Settings Group Policy Preference or with a Group Policy Preference registry item.

(Home) location:
Registry key: HKEY_CURRENT_USER\Control Panel\International\Geo
Registry value: Nation (REG_SZ)
You can configure the (home) location with a Group Policy Preference registry item.

Configuring regional settings using Group Policy

This section deals with the settings configured on the first tab, Formats, of the Regional Settings Control Panel item.

Configuring Regional Settings and Windows locales with Group Policy - Regional Settings Format tab

Ever since the introduction of Group Policy Preferences with Item-Level Targeting (first introduced with Windows Server 2008), managing regional settings has been a breeze. Open your Group Policy Management Console (GPMC.msc) and navigate to User Configuration \ Preferences \ Control Panel Settings \ Regional Options. With a right-mouse click on Regional Options select New.

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Regional Settings

Now you can configure your settings the same way as on a local Regional Settings pane.

Configuring Regional Settings and Windows locales with Group Policy- Group Policy Regional Settings regional options tab

Note: please be aware that this policy item requires you to first enable underlined settings by pressing the F5 or F6 key before you can modify and save them! See the Microsoft article Enable and Disable Settings in a Preference Item for more information.

I recommend to execute this policy in the user's security context (tick the Run in logged-on [...] box on the Common tab).

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Preference common tab run in users context

In case you require multiple Regional Settings configurations within the same Group Policy, use an Item-Level Targeting filter.

Configuring Regional Settings and Windows locales with Group Policy - Configure multiple regional settings

One way to distinguish users is to filter based on Active Directory security group membership, for example:

  • German (Austria): filtered on the Active Directory Group usrsAustria
  • French (France): filtered on the Active Directory Group usrsFrance
  • English (United States): filtered on the Active Directory Group usrsEnglish

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Regional Settings Item-Level Targeting button

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Regional Settings Item-Level Targeting

In the end, all regional settings are configured in the registry in the HKEY_CURRENT_USER hive. The regional settings consist of multiple values. You find all settings in the following registry key:

Control Panel\International

Configuring the 24/12 hour clock and AM/PM using Group Policy

It may happen that after configuring the regional settings for a user, the time in the system tray is not shown in the correct format. You can correct the time format on the Time tab in the Regional Settings Group Policy Preference (see also the previous paragraph) or directly in the registry (using either a script or a Group Policy Preference).

 

 

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Regional Settings time tab

Please take a look at the screenshot below. The regional settings have been modified from English (United States) to German (Austria). In most countries in Europe, a 24-hour clock is used without AM / PM at the end. In the example below, the time is not displayed as it should be. In our example, a 12-hour clock is displayed as well as AM / PM (nachm. stands for PM in German). What the clock should display is a 24-hour time notation without AM / PM at the end.

Configuring Regional Settings and Windows locales with Group Policy - Short time not modified

The short time value determines how the time in the system tray is displayed; a 24 or 12-hour clock (with or without leading zeros) and with or without AM / PM. This value is written in the registry in the HKEY_CURRENT_USER hive. The exact registry key and value are:

Control Panel\International -> sShortTime (REG_SZ)

The following possible values exist:

  • h:mm = 12-hour clock without leading zeros and without AM / PM
  • hh:mm = 12-hour clock with leading zeros and without AM / PM
  • h:mm tt = 12-hour clock without leading zeros and with AM / PM
  • hh:mm tt = 12-hour clock with leading zeros and with AM / PM
  • H:mm = 24-hour clock without leading zeros and without AM / PM
  • HH:mm = 24-hour clock with leading zeros and without AM / PM
  • H:mm tt = 24-hour clock without leading zeros and with AM / PM
  • HH:mm tt = 24-hour clock with leading zeros and with AM / PM

A capital H sets the clock to a 24-hour format; a small h sets the clock to a 12-hour format. A double hh or HH adds a leading zero (when the hour is one digit only). If tt is present at the end than AM / PM is displayed. Also, note the space between the clock settings and the tt value.

Here are some examples:

  • h:mm = 7:30 or 10:42
  • hh:mm = 07:30 or 10:42
  • h:mm tt = 7:30 AM or 10:42 PM
  • hh:mm tt = 07:30 AM or 10:42 PM
  • H:mm = 7:30 or 23:42
  • HH:mm = 07:30 or 23:42
  • H:mm tt = 7:30 AM or 23:42 PM
  • HH:mm tt = 07:30 AM or 23:42 PM

The last two examples in the previous list will not be used much in practice: a 24-hour clock with AM / PM at the end. The drop down menu in the Regional Settings does not allow you configure this, but you can configure this on the Time tab of the Regional Settings Group Policy Preference and by directly configuring the registry (using a Group Policy Preference registry item for example). Adding the prefix AM / PM to a 24-hour clock notation looks a bit weird, but it is technically possible:
Configuring Regional Settings and Windows locales with Group Policy - Short time 24-hour including am an pm

Now we have all the information we need to set the correct time configuration for all users. There are two easy ways how to accomplish this:

  1. Configure the clock using a Regional Settings Group Policy Preference
  2. Configure the clock using a Group Policy Preference registry item

Configure the clock using a Regional Settings Group Policy Preference

Please read the section Configuring regional settings using Group Policy in this article to understand how to configure the user's regional settings. After you have configured at least one regional setting configuration, modify this configuration and go to the Time tab.

On this tab you can modify the time format to anything you want. Before you can modify anything, first make sure to press the F5 button to turn all the red lines to green lines. Green lines indicate that anything you change will be saved after clicking the Apply or OK button. At the bottom of the tab a detailed description of the various configuration options is provided. In the example below I changed the format HH:mm:ss to h:mm:ss tt, changing the clock from a 24-hour to a 12-hour clock and adding AM / PM.

Configuring Regional Settings and locales with Group Policy - Regional Settings Group Policy Preference Time tab

Configure the clock using a Group Policy Preference registry item

Open your Group Policy Management Console (GPMC.msc) and navigate to User Configuration \ Preferences \ Windows Settings \ Registry. With a right-mouse click on Registry select New \ Registry Item. Configure the registry item as follows:

  • Action: replace
  • Hive: HKEY_CURRENT_USER
  • Key path: Control Panel\International
  • Value name: sShortTime
  • Value data: <your value>, e.g. HH:mm

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Preference set short time

I recommend to execute this policy in the user's security context (tick the Run in logged-on [...] box on the Common tab).

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Preference common tab run in users context

In case you require multiple locations for a variety of scenarios within the same Group Policy, use an Item-Level Targeting filter. This is explained in the section Configuring regional settings using Group Policy.

 

 

The registry item is now created and will be deployed to all users to whom the particular Group Policy applies. Configuring Regional Settings and Windows locales with Group Policy - Group Policy Preference short time configured

It is possible to rename the registry item afterwards:

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Preference short time rename

Just remember that modifying the item resets it to its original name (=the value name) and you will have to rename it again.

Configuring the (home) location setting using Group Policy

This section deals with the Home Location setting configured on the second tab, Location, of the Regional Settings Control Panel item.Configuring Regional Settings and Windows locales with Group Policy - Regional Settings Location

The location cannot be changed using the Regional Settings Group Policy Preference. Instead, a Group Policy Preference registry item needs to be used.

The location is stored in the Windows registry in the HKEY_CURRENT_USER hive. The exact registry key and value are:

Control Panel\International\Geo -> Nation (REG_SZ)

Configuring Regional Settings and Windows locales with Group Policy - Regional Settings Location tab and registry

To determine the country ID, change the location manually on the second tab of the Control Panel item Regional Settings and than check the aforementioned registry value. For example, when I select Austria as my location, the value Nation is set to 14. Before it was 244, which is the country ID for the United States.

Now we have all the information we need to set the correct location for all users. The easiest way to accomplish this is by using a Group Policy Preference.
Open your Group Policy Management Console (GPMC.msc) and navigate to User Configuration \ Preferences \ Windows Settings \ Registry. With a right-mouse click on Registry select New \ Registry Item. Configure the registry item as follows:

  • Action: replace
  • Hive: HKEY_CURRENT_USER
  • Key path: Control Panel\International\Geo
  • Value name: Nation
  • Value data: <your value>, e.g. 14

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Location

I recommend to execute this policy in the user's security context (tick the Run in logged-on [...] box on the Common tab).

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Preference common tab run in users context

In case you require multiple locations for a variety of scenarios within the same Group Policy, use an Item-Level Targeting filter. This is explained in the section Configuring regional settings using Group Policy.

The registry item is now created and will be deployed to all users to whom the particular Group Policy applies.

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Preference location configured

It is possible to rename the registry item afterwards:

Configuring Regional Settings and Windows locales with Group Policy - Group Policy Preference location rename

Just remember that modifying the item resets it to its original name (=the value name) and you will have to rename it again.

I hope this article was of some help to you.

Share this post:
Dennis Span on EmailDennis Span on LinkedinDennis Span on Twitter
Dennis Span
Dennis Span
Dennis Span works as a Senior Citrix Architect for a large insurance company in Vienna, Austria. He holds multiple certifications such as CCE-V, CCIA and CCEA. In 2017, Dennis became a Citrix Technology Advocate (CTA). In 2019, he became a Citrix Technology Professional (CTP). Besides his interest in virtualization technologies and blogging, he loves spending time with his family as well as snowboarding, playing basketball and rowing. He is fluent in Dutch, English, German and Slovak and speaks some Spanish.

23 thoughts on “Configuring Regional Settings and Windows locales with Group Policy

  1. Pingback: Managing Windows Languages and Language Packs - Dennis Span

  2. Hey Dennis,

    thanks for the great article. I will reference it in my documentation. 🙂

    The correct value for “Nation” for Spain seems to be 217, by the way.
    Probably an alphabetical list of some sort…

    Regards,
    Stefan

  3. Hello Dennis,
    I tried to use this solution on some Windows Server 2016 VMs in my Azure subscription.
    The option “Control Panel Settings/Regional Options” is not present in my GP Editor, and the Option “Run in logged-on user’s security context” is permanently disabled an cannot be set.

    Therefore, I am not able to promote any of those settings via GPO.

    Have you ever seen anything like this? Do you have any hint where to look?

    Best regards

    Joerg

  4. Hello Dennis,

    Thanks for the article, however how can we apply a GPO to change the date format to a group of computers no matter who is logged in. Our target is computer and not user.

    Thanks
    Rajesh

    • Hi Rajesh,

      Good question. By default, the date and time format of the local system is copied to new user profiles. But in the end, the date and time format is a user-specific setting. My point is that displaying different date and time formats on different servers still requires you to change settings for the user.

      I would proceed as follows:
      1) Enable loopback processing mode on all servers (this is a machine-specific policy);
      2) Create a separate OU that reflects each date and time format you may need (e.g. “DateTimeUS”, “DateTimeIndia”, “DateTimeSpain”);
      3) Move your servers to their appropriate OUs;
      4) Create one group policy per OU in which you configure the correct date and time format (user configuration, not machine).

      This solution will change the date and time format according to the server’s assigned OU for each user at logon time. Optionally, create separate user profiles for these server groups.

  5. Hi Dennis,
    Thanks for the artical,
    I have just one question.
    We have an RDweb server with already published a application and we have different users from different part of the world that access the same app on the same server. If I understood you correctly we can use your steps to set the regional settings for different locations.
    Does this policy works only for the new users that are going to start the published app or when the policy linked to an OU the old users will get also the settings?

    Thanks

  6. It looks like that Dennis suggestion work very good when users accessing the Full RDP.
    I did run a test and create the policy, Now when an old or new user access the RDP they get the settings of the gpo, but when the same user access an published app on the same server the user still get seting of the local server

    Is my finding correct?

    • Hi Shahin,

      I assume that you configure the regional settings using a Group Policy Preference as described in my article. In this case it should not matter whether a user starts a desktop or a published application.

      • Hi Dennis,

        The policy that we use has a user configuration and never mind on which RDS server the application is installed and published, when a user open the published application it should have the French time format.
        I setup a Windows 7 French language and then access the rdweb and start the published app but when click in the box where we can type the date I can see that my language automatically change to dutch!!
        Any suggestion?

      • Hi Dennis,

        I followed your steps and setup only the group policy and not the registry settings.
        Did you had the chance to test this also with a published app?
        we have a 3rd party app and as I meantioned when user accessing it from the full RDP connection everything works correctly but not when start the same app from the Rdweb.
        I have no idea with whitch windows application I can test this.

        • Hi Shahin,

          My apologies, but I am not sure how to help you. In your various comments you are referring to regional settings, time zone as well as the Windows language; these are all separate configurations and need to be considered and configured independently from each other. If you want my help than please send me an e-mail with as many details as possible through my contact form on my About page.

  7. Great article, the most thorough guide I found for GPO and regional settings. I applied the policy for regional settings but unfortunately, it is not working on our environment. I am getting Result: Failure (Error Code: 0x800704ec).
    Can you please advise me how can I troubleshoot ?

    • Hi Dimitrios. I am happy you like the article. Concerning the error code; can you send me more information. For example on which operating system are the policies applied? Also, did you configure Item-Level Targeting (ILT) on the Regional Settings configuration? If yes, which ones? Also, try if the regional settings work without configuring ILT.

  8. The policies are applied on windows 1903 clients 64 bit. DC runs on Windows 2012R2 and DC functional level is 2003. ILT is not used.

      • Hi, sorry for my late reply.

        Unfortunately cannot attach files to provide gpresult. The error displayed on the HTML is Result: Failure (Error Code: 0x800704ec) under control panel settings. Should I check on event viewer ?

  9. Checked event viewer on the client:

    The user ‘Greek (Greece)’ preference item in the ‘ANM_Regional_CU {0BFA4A3D-4359-4AE9-8683-E4821BCF1E12}’ Group Policy Object did not apply because it failed with error code ‘0x800704ec This program is blocked by group policy. For more information, contact your system administrator.’ This error was suppressed.

    It seems that there is a different GPO blocking application of regional settings?

    • Hi Dimitrios. The error message clearly states that the program is blocked by group policy. Can it be that you have Software Restriction Policies or App Locker settings active? Perhaps something is not configured correctly.

  10. After checking multiple times and checking GPO conflicts using MS Policy Analyzer, it turned out that there was no other GPO conflicting with the GPO created for Regional Settings.
    I created a single GPO aggregating user (regional) & computer settings (timezone ). It turned out that timezone registry keys from the wizard were causing the problem. After I removed them ‘0x800704ec This program is blocked by group policy. For more information, contact your system administrator.’ disappeared.

  11. Finally !!! I found the setting to blame !!!
    Your timezone & regional settings along with the following setting ENABLED:
    Computer Configuration\Policies\Administrative Templates\System\Locale Services\Disallow user override of locale settings
    will cause Failure (Error Code: 0x800704ec).
    Setting back to Not configured resolves the error.

Leave a Reply

Your email address will not be published.

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.