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.
After updating the settings you might want to restart your machine, or at the least recycle your application pool (or for IIS 5.1, kill the aspnet_wp process).
Hope this helps someone.
Additional: The scenario I wrote about describes a system that depends on the culture of the account that runs the application pool process. If you build a web application and you want it to use a specific culture, don’t become dependant on the culture of a specific account, instead use the <system.web>\<globalization> section and set the culture attribute to define the specific culture you want to use in the application. This way you can deploy your application to any server, without having to worry about mismatching server configuration.