Sharing an experience and looking to validate some of the challenges vPro demonstration might present in markets outside of North America - especially if the original demonstration environment was created in North America.




A few weeks ago I had the opportunity to travel to Germany for a training event.   The equipment for the training event was sourced locally in Germany.   The result was 13 systems.  (For those that are superstitious – you might quickly identify that this will get interesting).  




Among those 13 systems, there were 4 different OEMs, 3 different keyboard layouts (US, UK, German), 3 different power connectors, 2 generations of Intel AMT (2.6 and 4.x), 3 different versions of Windows (XP, Vista, and Win7), 2 different versions of VMware workstation, and a single VMware workstation image created in North America.   Very little standardization.   A perfect recipe for disaster.




This was my first experience in working with differences that went beyond just QWERTY vs. QWERTZ keyboards.   The password used for the operating system and applications included the @ key.   This was problematic since on a US-based keyboard the location of '@' is Shift-2, yet a German keyboard is AltGr-Q  (press and hold key to right of spacebar, then press Q), and a UK-keyboard is Shift-‘ (press and hold shift, then press ‘ key which is located on third row third key from the right side).   Fortunately I didn’t have to deal with keyboards outside of Latin letters (i.e. A, B, C, etc) – although there are exceptions like the German letter β.





My first realization of internationalization troubles was that BIOS\MEBx screens and key sequences were US-keyboard QWERTY based regardless of the keyboard layout.   I had to ask myself - "Is this always true?".   Since the password included the @ symbol - mentally I had to follow the US-keyboard layout, althought the sequence wouldn't match the printed keys on the system.




When in the host operating system, the “Regional and Language settings” were commonly set to the origin of that system (expect one system which had UK keyboard with US-based Windows Regional and Language settings).   My frustration did not end there – as the VMware environment was set to US-based Regional and Language settings, and had to be adjusted on a per-system configuration basis.



Not all of the windows menus and options were in the same locations between English and German, yet there were similarities.   With the differences of languages between BIOS\MEBx, host windows operating system (with VMware workstation), and demonstration environment – some real-time translation or best guess had to be done.  I know some German, thus I was able to navigate through menus in the host operating system or VMware application, yet it slowed setup and troubleshooting situations.   Fortunately those attending the training knew English better than my German language skills... but frustrating nonetheless.




The good news – the underlying vPro functionality was the same, the training was delivered, and a new perspective was obtained by myself and those who received the training.



In talking with my international associates, a few more points were brought to my attention:

  • difference of calendars (for example, those that use Buddhist calendaring system) which may affect Kerberos and certificates
  • application installations may fail when using a foreign language
  • Remote configuration certificate is issued to one domain (i.e. yet will not support international domains (i.e. this one is actually fixed in the latest firmware and will be explained in a separate article





There are likley other subtleties to the challenges of internationalization




Does this all sound familiar to those outside of the US?  




The experience was good for me.   I gained a brief look into much larger challenges on standardizing a technology solution across the globe.