Names of Default Collections Use Language of Central Site
Any collection, package, or advertisement that is passed down a hierarchy assumes the name it was assigned at the site where it was created, and it appears with that same name throughout the hierarchy. The default collections are a special case of this.
When each site is created, the default collections are created at that site, and the name of the collection reflects the site's language. When the site attaches to a parent site, the collection definitions for the default collections are overwritten with the definitions used at the parent site. If the child and parent use different languages, the collection names are in the language of the parent site. This extends all the way up the hierarchy: default collections are assigned the name used at the central site. The implications of this depend on the code pages used by the affected sites:
If the two sites use the same code page, the SMS Administrator console at the child site displays the collection name correctly, but it is in the language of the central site.
If the two sites use different code pages, the SMS Administrator console at the child site cannot display the collection name correctly. The names of the default collections are unreadable.
WORKAROUND: If the two sites use the same code page, administrators at the child site must learn to recognize the of the default collections' names when they are in the language of the central site.
If the two sites use different code pages, at the central site, rename the default collections to use only ASCII characters. The collection names are then displayed correctly at all sites. In addition, assign ASCII-only names to all collections, packages, and advertisements at any site that is or might be a parent to a site that uses a different code page.
An alternative method is to maintain an SMS Administrator console at the child site on a computer that uses the language of the central site.
If SMS Site Server Code Page Does Not Match Code Page of Operating System, Extended/DBCS Characters Used in Active Directory Are Garbled using any Active Directory Discovery Method
SMS 2003 Active Directory Discovery converts Unicode strings to ASCII/DBCS before inserting data into SQL Server, based on the SMS site server language. If you enter DBCS/Extended characters in Active Directory on an English-language SMS site server, the DBCS/Extended characters are corrupted throughout the database because the codepages do not match. This affects objects, such as organizational units and user names.
WORKAROUND: If available, use a localized SMS site server that matches the operating system that you are using, for example, a Japanese SMS site server and a Japanese operating system. Otherwise, it is recommended that you use ASCII characters in Active Directory.
Web Reports and HTTP Downloads Do Not Work When SMS Resource Names Contain Simplified Chinese Characters
SMS resources, such as Web page names, distribution point names, and computer names that contain simplified Chinese characters, prevent Web reports and HTTP downloads from working properly. This issue affects computers running IIS 5.0 on Windows 2000 SP4.
WORKAROUND: If any Web page names, distribution point names, or computer names in your SMS site contain double-byte character set (DBCS), you can edit the following registry entries on the computer that is running IIS 5.0 to enable Web reports and HTTP downloads:
Type = REG_DWORD
Name = FavorDBCS
FavorDBCS = 0
After you edit the registry, you must restart the server for the changes to become effective.