SCVMM 2008: Reports generated from OpsMgr 2007 SP1 in Japanese change back to English after a few days

You have an environment where SCVMM 2008 is installed with Operations Manager integration. When you run a report using the Japanese version of Operations Manager, the initial reports show up properly in Japanese. After about two days, when you go to run the report again, you will find the language is changed back to English.

This has confirmed to be a problem on the SC Operations Manager 2007 side. It has been a confirmed to be a bug in 2007 SP1.

There is no workaround although the issue has been fixed for System Center Operations Manager 2007 R2.

There will be no hotfix for SP1.

The best resolution is to upgrade the Operations Manager environment to 2007 R2.

Do not Use App-V for Legacy Locale/Regional Settings Compatibility – Use AppLocale

Recently, we have had some customers asking us about leveraging App-V to virtualize locales. You may also refer to them as regional settings. Since Windows 2000, the Windows operating system has been multi-locale aware and is able to preserve user-specific locales.

The user locale determines which default settings a user wants to use for formatting dates, times, currency, and large numbers. The user locale is not the language. The only influence the user locale has on the language is on the names of the days and months. For example, if you use the long date format to display “April 22, 2010,” the “April” string will change based on the user locale.

Changing the user locale automatically adds an Input Locale with the default settings for the associated language. I made some serious tests involving easily discernable applications with regional setting differences (locale differences.) While the operating system now support user locales, there are still legacy applications that only recognize system locales. Some of these applications may be hard-coded to correspond to a specific locale.

App-V is language or locale neutral and should have full support for different languages and character scripts, sorting orders, time/date/address formats, various International keyboards and global Input Method Editors (IME), and other locale settings.  This approach is called “single World-Wide binary”.

It is important to understand that while we are locale aware, the actual isolation and sandboxing of the locale regional settings takes place at a system level even though the preferences are stored at the user profile level.  App-V is not expected to make the application localized or culture-aware if it’s not already supported. It won’t make the application to work on a culture that the application does not originally support in the locally installation.

If it were as simple as simple as making registry modifications within the virtual environment, this may would work.  Most locale-aware applications, however  will actually call API’s directly in Windows whether they are user locales or system locales. For example, retrieving  the user locale by calling GetUserDefaultLCID and the system locale by calling GetSystemDefaultLCID. When the application is calling the API directly, it is not reading the registry entries because it is calling the Win32 API directly and it will be querying the registry – but outside the virtual environment.

AppLocale

We recommend that users look to the AppLocale Utility as a possible remediation. The AppLocale utility allows users to run a legacy application without changing to the code-page/system locale needed by that particular application. AppLocale emulates the code-page required by that legacy application without changing the machine’s system locale. This can provide the “sandbox” you may need for the application’s locale.

AppLocale Information:

http://www.microsoft.com/globaldev/tools/apploc.mspx

Download:

http://go.microsoft.com/fwlink/?LinkId=17598