A few years ago I’ve stumbled on a very annoying scenario on my machine: I had used ASP.NET’s development server (the web server that pops up when debugging web applications in Visual Studio) while developing a web application and when I moved my web application to my local IIS, suddenly the culture of the thread changed from my local culture (he-IL) to a Greek culture (el-GR).
This was a few years ago, and took some time to solve, and I though I had the unfortunate luck of being the owner of a weird installation of Windows 2003 server, but in the last 24 hours I’ve encountered three different computers that had a similar problem, where some of them decided that IIS should run on an English culture (en-US) and some on a French culture (fr-CH).
First of all, the reason IIS runs on a different culture than the ASP.NET’s development server is that the ASP.NET’s development server runs under the account of the user that is currently logged in, while IIS’s application pools runs under a different account:
For Windows XP with IIS 5.1, the user is ASPNET (a local account created by the .NET Framework)
For Windows 2003 and on (Vista, 7, 2008 server) with IIS 6 or 7.X, the user is Network Service (unless specified otherwise in the application pool configuration).
The reason why the Network Service account uses a different culture can usually be traced back to the installation of the operating system. The culture of newly created accounts is decided according to the regional settings of the default user, and the Network Service account is set when the operating system is installed. So if you install your windows with the English - United States settings which is usually the default culture, the account will use the en-US culture. In my case, someone probably missed the Hebrew option and selected Greek by mistake.
To fix this problem, you’ll need to change the regional settings of these special accounts (network service, local service, aspnet etc…). Fixing this depends on your operating system:
For Windows Vista and on (7, 2008 server) this is quite easy, just follow the steps specified in the following link.
For Windows 2003 and XP, you’ll need to edit the registry manually:
Open the registry, and export the “CURRENT_USER\Control Panel\International” branch. This branch contains the regional settings of the current user.
Under the HKEY_USERS hive, for each SID (security identifier) and for the .DEFAULT user perform the following steps:
Edit the exported registry file and set the path of the two sections to the account you want to fix. For example, to fix the network service account, change the “HKEY_CURRENT_USER\Control Panel\International” branch to “HKEY_USERS\S-1-5-20\Control Panel\International”.
Double-click the reg file to import it to the registry.
Return to the registry editor and check that the International branch was updated successfully for the account.
If you want to see which SID belongs to which builtin account, you can look at the following list.
Read more: Ido Flatow
This was a few years ago, and took some time to solve, and I though I had the unfortunate luck of being the owner of a weird installation of Windows 2003 server, but in the last 24 hours I’ve encountered three different computers that had a similar problem, where some of them decided that IIS should run on an English culture (en-US) and some on a French culture (fr-CH).
First of all, the reason IIS runs on a different culture than the ASP.NET’s development server is that the ASP.NET’s development server runs under the account of the user that is currently logged in, while IIS’s application pools runs under a different account:
For Windows XP with IIS 5.1, the user is ASPNET (a local account created by the .NET Framework)
For Windows 2003 and on (Vista, 7, 2008 server) with IIS 6 or 7.X, the user is Network Service (unless specified otherwise in the application pool configuration).
The reason why the Network Service account uses a different culture can usually be traced back to the installation of the operating system. The culture of newly created accounts is decided according to the regional settings of the default user, and the Network Service account is set when the operating system is installed. So if you install your windows with the English - United States settings which is usually the default culture, the account will use the en-US culture. In my case, someone probably missed the Hebrew option and selected Greek by mistake.
To fix this problem, you’ll need to change the regional settings of these special accounts (network service, local service, aspnet etc…). Fixing this depends on your operating system:
For Windows Vista and on (7, 2008 server) this is quite easy, just follow the steps specified in the following link.
For Windows 2003 and XP, you’ll need to edit the registry manually:
Open the registry, and export the “CURRENT_USER\Control Panel\International” branch. This branch contains the regional settings of the current user.
Under the HKEY_USERS hive, for each SID (security identifier) and for the .DEFAULT user perform the following steps:
Edit the exported registry file and set the path of the two sections to the account you want to fix. For example, to fix the network service account, change the “HKEY_CURRENT_USER\Control Panel\International” branch to “HKEY_USERS\S-1-5-20\Control Panel\International”.
Double-click the reg file to import it to the registry.
Return to the registry editor and check that the International branch was updated successfully for the account.
If you want to see which SID belongs to which builtin account, you can look at the following list.
Read more: Ido Flatow