Installing Server-Media-Foundation in a Docker Container

Docker Desktop for Windows
1

Crossref: https://www.reddit.com/r/docker/comments/57w70v/installing_servermediafoundation_windows_feature/

Trying to install the Windows version of Plex inside a Windows Server 2016 container. Our results thusfar:https://www.reddit.com/r/PleX/comments/5746vh/pms_installation_in_windows_server_2016_docker/
Server and client:

Version: 1.13.0-dev

API version: 1.25

Go version: go1.7.1

Git commit: 9f5ffa2

Windows Server 2016 RTM MSDN Using microsoft/windowsservercore as base image.

Plex installs and files are placed in the correct places. However, when trying to run Plex Media Server.exe, it just quits. Docs on the internet note that you need the ServerMediaFoundation feature on Windows Core installed in order for Plex to run.

Tested this: New 2016 Core VM, Plex installed, doesn’t run. Installed the ServerMediaFoundation feature and rebooted: Plex works.

I think we’re really stuck on the installation of the ServerMediaFoundation feature inside the docker container. The features appears to install and demands a reboot. Rebooting makes the docker container stall. Stopping and restarting the container shows the feature is not installed.

Hardcore docker, especially on Windows, is new to me but I’m going to make a wild guess here: Could the feature installation depend on image modifications of the microsoft/windowsservercore image? Like, it needs to inject into the kernel which is shared between images/containers?

In short: Is it possible to run Dism /online /enable-feature /all /FeatureName:ServerMediaFoundation and make it work? Or does one have to hack the crap out the Microsoft/WindowsServerCore image (which isn’t allowed by EULA I believe)?

Dockerfile:

FROM microsoft/windowsservercore

LABEL Description=“PMS”

COPY PlexInstaller.exe C:\

COPY install-media.bat C:\

RUN C:\install-media.bat

RUN PlexInstaller.exe /install /quiet

RUN del C:\PlexInstaller.exe

RUN del C:\install-media.bat

CMD [ “cmd” ]

Install-media.bat (nasty hack to get correct error code from DISM):

Dism /online /enable-feature /FeatureName:ServerMediaFoundation /NoRestart

ver > nul

TL;DR: Is it possible to install the Server-Media-Foundation feature inside a Microsoft/WindowsServerCore image on Windows Server 2016 RTM?

1 Like
2

I am facing similar issues when trying to install missing windows features (in my case for example “DirectAccess-VPN” but this is not the only one).

I can see several problems that spread around windows feature installations.

  • The first one is a lack of any documentation about windows features that require OS/container restart after installation finishes.

  • I was trying to install and reboot in an interactive console directly in a running container, no success. The container hangs each time rebooted. Similar problems reported here: superuser.com.

  • Then I was trying to install those features directly in the Dockerfile as I had found some feedback about committing of each step inside Docker Build process (source: msdn - Patrick Lang - 27 October 2016). Patrick Lang says: “In general, this is an ok way to go in a Dockerfile. Each RUN command does a commit before executing the next line. That should replace the need for a reboot.”

  • The previous one does not seem to be a true statement, or at least I can`t achieve what I expect. I can demonstrate it on the simple dockerfile:

    FROM microsoft/windowsservercore
    SHELL [“powershell”, “-command”]
    RUN Install-WindowsFeature DirectAccess-VPN
    RUN Get-WindowsFeature DirectAccess-VPN
    CMD powershell.exe

You can see that the first RUN installs the feature, the second RUN reports that the feature has been installed. But when running a container based on the image you can see that the feature is still missing (available to install).

Maybe the feature is not meant to be installed in the Windows Container but as I`ve stated - I can see some lack of documentation of this area.

Client:
Version: 1.14.0-dev
API version: 1.25
Go version: go1.7.3
Git commit: 851d914
Built: Sat Nov 12 04:38:59 2016
OS/Arch: windows/amd64

Server:
Version: 1.14.0-dev
API version: 1.25
Minimum API version: 1.24
Go version: go1.7.3
Git commit: 851d914
Built: Sat Nov 12 04:38:59 2016
OS/Arch: windows/amd64
Experimental: false

3

I was trying to install all components via Dockerfile (docker build) and validate results somehow during the installation process and of course while running a container based on the image as well.
Validation based on the running container is always negative. The feature has never been installed successfully (Available to install).
Some interesting results can be seen when fiddling with build commands in the Dockerfile. I have created two Dockerfiles/two scenarios:

Scenario 1 - Dockerfile:
FROM microsoft/windowsservercore

SHELL ["powershell", "-command"]
# 1) Install the feature.
RUN Install-WindowsFeature DirectAccess-VPN
# 2) Validation method - try to install the feature again and see results.
RUN Install-WindowsFeature DirectAccess-VPN
# 3) Validation method - verify the feature has been installed using Get-WindowsFeature.
RUN Get-WindowsFeature DirectAccess-VPN

CMD powershell.exe

Scenario 1 - Output:
Sending build context to Docker daemon 5.632 kB
Step 1/6 : FROM microsoft/windowsservercore
—> f49a4ea104f1
Step 2/6 : SHELL powershell -command
—> Running in 8b0b1d3bdd9e
—> 2f5b86efab25
Removing intermediate container 8b0b1d3bdd9e
Step 3/6 : RUN Install-WindowsFeature DirectAccess-VPN
—> Running in a107a50d708b

Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    Yes            SuccessRest... {DirectAccess and VPN (RAS), Remote Ac...
WARNING: You must restart this server to finish the installation process.


 ---> b1793ba9d7fc
Removing intermediate container a107a50d708b
Step 4/6 : RUN Install-WindowsFeature DirectAccess-VPN
 ---> Running in e79643960673

Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             NoChangeNeeded {}


 ---> 196408173637
Removing intermediate container e79643960673
Step 5/6 : RUN Get-WindowsFeature DirectAccess-VPN
 ---> Running in c98adaa1c581

Display Name                                            Name
------------                                            ----
    [ ] DirectAccess and VPN (RAS)                      DirectAccess-VPN


 ---> 218e17bce9b4
Removing intermediate container c98adaa1c581
Step 6/6 : CMD powershell.exe
 ---> Running in b7a7e101a05b
 ---> 40130475bcd1
Removing intermediate container b7a7e101a05b
Successfully built 40130475bcd1

Scenario 2 - Dockerfile:
FROM microsoft/windowsservercore

SHELL ["powershell", "-command"]
# 1) Install the feature.
RUN Install-WindowsFeature DirectAccess-VPN
# 3) Validation method - verify the feature has been installed using Get-WindowsFeature.
RUN Get-WindowsFeature DirectAccess-VPN
# 2) Validation method - try to install the feature again and see results.
RUN Install-WindowsFeature DirectAccess-VPN

CMD powershell.exe

Scenario 2 - Output:
Sending build context to Docker daemon 5.632 kB
Step 1/6 : FROM microsoft/windowsservercore
—> f49a4ea104f1
Step 2/6 : SHELL powershell -command
—> Running in 694f6b3752ad
—> 15240045f5bc
Removing intermediate container 694f6b3752ad
Step 3/6 : RUN Install-WindowsFeature DirectAccess-VPN
—> Running in 7ac12553ea10

Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    Yes            SuccessRest... {DirectAccess and VPN (RAS), Remote Ac...
WARNING: You must restart this server to finish the installation process.


 ---> 469002ee0b41
Removing intermediate container 7ac12553ea10
Step 4/6 : RUN Get-WindowsFeature DirectAccess-VPN
 ---> Running in 62f6c230ea12

Display Name                                            Name
------------                                            ----
    [X] DirectAccess and VPN (RAS)                      DirectAccess-VPN


 ---> fc6af83a6c98
Removing intermediate container 62f6c230ea12
Step 5/6 : RUN Install-WindowsFeature DirectAccess-VPN
 ---> Running in 91d57cfc366c

Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    Yes            SuccessRest... {DirectAccess and VPN (RAS), Remote Ac...
WARNING: You must restart this server to finish the installation process.


 ---> aad383b0b070
Removing intermediate container 91d57cfc366c
Step 6/6 : CMD powershell.exe
 ---> Running in 1a07e0f02d03
 ---> f630dc7b78f6
Removing intermediate container 1a07e0f02d03
Successfully built f630dc7b78f6

Result:
As you can see in the second version I change an order of the commands (command 2 and 3) and I would expect the same results even when an order has been changed. But this is not true.
Maybe I wrong when watching the results of the build process in this way. Maybe this behaviour coincide with features that are not supported to be installed inside Windows Containers (in this case I would expect some error message saying that).

4

Yeah it’s really weird how the engine / kernel seems to respond to a query on the installstate of certain features. I think it might have something to do with the features relying on kernel transactions but those as disabled in Windows-on-Docker.

Thank you for also replying to my MSDN topic. I’ll also repost it there. Microsoft / Docker support is dead (on arrival).

5

I finally managed to get Server-Media-Foundation installed and working in Windows Server 2016 Docker container

I wrote a small article about it with further details

Quick steps to build Docker image

  1. Make sure to use a base image that is based off microrosft/windowsservercore build number 14393 (Windows Server 2016)
  2. Patch up all the C:\Windows\servicing\Packages*.mum and remove any restart=“required” attributes
  3. Install-WindowsFeature Server-Media-Foundation
  4. You can do some basic validation that MF is working now, see Validation below
  5. Now you should be good to go…

Docker file and script

You can find a Dockerfile and the script used to patch up the .mum files on here on GitHub

6

Using a newer build of the Windows Server docker (like 1709) also fixes the issue.
Thanks for replying :slight_smile: