This is a tough call -- I personally have first hand experience with the challenges encountered in multi language environments: Asia Pacific seems to be the land of the double byte character set languages .

• What does moving to unicode only do for down level support? Currently we can still manage old clients from new core servers.  Will inventory coming from older clients be an issue?
• What about multi core environments? Originally, when this discussion began the thought was that the Rollup Core would support unicode and some sort of translation to support collecting data from cores using various different codepages.  Does this suggest that all cores and clients have to be upgraded to maintain rollup functionality?
• It is noted that a new database container (for SQL200x) will be needed.  In 2005, you can set the database collation at both the server level during installation, and then set databases to use collations different from that which is set at the server level.  I vaguely recall opening a case on this to find that LDMS uses the server collation and not that of the database -- if this is still the case, won't this require that we have customers install a separate SQL instance to support LDMS if their server collation is 1252 or something else?
• What impact, if any, will this have on other products, such as process manager or ALM, which are (according to the installation guide) to be set up on a SQL instance and database using code page 1252-Latin 1?

My big concern, since we do not deal with different languages in our shop, is performance.  You mention query performance in the FAQ, will there be any other areas of the program that MAY suffer from going to Unicode?

Good point, however, I was going for more of what performance hits will this change have on overall use, not just queries. You are correct there will be things oozing out of the cracks that nobody ever thought off.

Mark - if I'm reading your post right, the core server will still only be able to properly process scan files from one code page?  For example it won't be able to accept both Chinese and Japanese client inventory scans?

Or is that only a limitation for backwards compatiblity and the new client inventory scanner will allow the core to accept both languages?

"The current consideration is whether or not to support, in addition to Unicode, the older code-page based language capability.  Our current research has lead us to the design that would only support a Unicode implementation . "

We are very much looking forward to LANDesk's implementation of a Uni-code database that will enable a multi-language database.  We have no issue in creating a new database or the extra storage this will require temporarily during the migration.  We recommend LANDesk adapt a multi-language supported database, focus engineering resources solely this new format by discontinuing the older code-page database format, and ensure the new multi-language enabled database does not provide a downside to single language customers such as ensuring performance is not an issue and the migration is not painful.

With a multi-language enabled database we plan to consolidate our 7 databases (located in three locations) to 3 databases (located in 3 locations).

If agent upgrades are required to take advantage of this functionality we will require a more bandwidth considerate method of updating our 20,000 + global agents than pushing 20+MB agents 20,000 times over limited WAN links.   Our first preference would be to update the Inventory Scan via Security Suite.  If more of the agent requires upgrading, we would like to see the Advance Agent code corrected so it can be used for upgrading as well as first time installs as this method takes advantage of files on local subnet peers.

Mark --

A few more use cases based on a couple of things I've done during upgrade or install paths:

Doing a side by side core upgrade will often prompt me to have my customer create an alias in DNS to point the old core server name to the IP of the new core.  This way, we can get inventory and other functionality up quicker than we may be able to deploy agents.  Of course, we'd be using the keys from the old core.

Also, when I was doing an implementation for a China based customer who needed support for both simplified chinese (code page 936) and English Latin 1 (code page 1252), I configured the database to use code page 936 on all of the core server databases.  All of the cores and consoles (including the rollup) I installed under US English. With Asian Character support enabled in Windows, a console accessing a core would display the chinese characters if they were present in inventory.  This introduced a few functionality challenges, which I'll get to, but also allowed for the China headquarters to manage clients from sites in 99 countries without having to terminal service to cores around the world.  One core in a particular region recieves inventory scans from machines with English, Chinese, Japanese, Korean and other OS languages, though as far as I recall there is only the English version of the LANDesk agent being deployed across the boards (since the cores are all English).  This would contravene the upgrade case you mentioned about upgrading a core of a specific language and it only supporting that one language.  I should note, of course, that the other languages on the core in this region aren't supported by the database and come up as garble, but the English and Chinese (simplified) work fine.  I'm conscious of what may happen with them under the proposed initiative.

regarding server collation, I was poking through the documentation I put together for the customer and found more detail:

<CUSTOMER> has the requirement to support the existing LANDesk infrastructure, which is configured to use the Simplified Chinese Language and Character sets, as well as the solution in progress. Because the current solution uses Chinese, which is a double byte character set, the rollup core which will contain data from this solution, must also be double byte.   From an SQL server standpoint, this would mean that the server collation needs to be of a codepage that supports double byte character sets. In SQL Server 2005, this would generally not produce an issue, as the databases can have their own collation independent of the instance installed default, however testing indicated that the LANDesk rollup operations only seemed to use the server level collation versus the database.   As such, all LANDesk databases will be set to use code page 936 (Simplified Chinese). Additionally, to support the requirement to potentially access LANDesk and Windows by users native to both languages, it is strongly recommended to maintain support for both within the OS as well.   This can be achieved as detailed in the instructions provided by Microsoft in the link below:

# http://www.microsoft.com/globaldev/handson/user/xpintlsupp.mspx#E4

In reference to what Paul raised, I had a bit of a think about it during the aforementioned customer engagement and found the following would likely be the case with respect to challenges managing LANDesk in multi language environments:

LANDesk, which at this time doesn’t support Unicode, should work with other languages such as Japanese from a functionality standpoint.  The things I think with respect to this (and per discussions with others in the factory) are as follows:

• ·          Remote Control should work fine
• ·          Software Distribution should work fine
• ·          OS Deployment (not used) should work fine
• ·          Hardware inventory (overall) should work fine.  There are potential issues with this due to the possibility that some details pulled from BIOS comes from WMI and may be specific to the OS language.

What will definitely have issues:

·

•         Software License Monitoring: Application discovery may have some challenges due to the need to qualify applications based on names which might be specific to a language/locale setting
• ·          Policy Management: Policies that run based on LANDesk queries will have issues if the clients with unsupported character sets are targets.  This is because the clients may not properly report back to inven