none
Windows Containers on Windows 10 Pro identifies themselves as "Microsoft" instead of the Full OS Name RRS feed

  • Question

  • When running servercore containers on a Windows 10 Pro host, the Operating System Name does not identify itself correctly.

    Commands like:

    systeminfo

    and

    wmic os get name

    simply return "Microsoft" as the OS Name.

    Running these same commands in a container generated from the same Dockerfile when the host is a Server OS (tested with Server 2019), the commands return the correct OS Name.

    Here is a link to the github issue I opened: https://github.com/docker/for-win/issues/4665 .  It was closed and I was told to post the question here.

    Wednesday, September 11, 2019 1:25 PM

All replies

  • Greetings,

    Sorry for the inconvenience.

    I have replied your issue in github. By the way, do you have the business scenario for this issue? Are you using this name as identifier for tooling development?


    Sic Parvis Magna


    Friday, September 27, 2019 9:45 AM
  • I'm working to dockerize some software that looks to this information for licensing. When running the container on Windows Server, it works fine. However, for the environment on my Windows 10 laptop, I'm unable to use the container.

    I'm working with the vendor to change how the software gathers this information, but it's obviously a Microsoft bug because it works fine on a Windows Server host, but not on a Windows 10 host.

    My guess is that they're using some API calls that are returning a null value when the container is running on a Windows 10 host, but those same API calls are returning with expected values on a Windows Server host.

    I should also note that the software works as expected when installed directly onto my Windows 10 laptop, without the use of a container.


    Friday, September 27, 2019 5:47 PM
  • Greetings,

    Thanks for providing the details. Based on the whole picture, it's about the "lifting and shifting" process of business applications.

    Microsoft may have a long period of time to fix this so-called "bug". You may consider to find a workaround.


    Sic Parvis Magna



    Sunday, September 29, 2019 3:42 AM