5 tips for IIS on containers: Bonus – IIS remote management

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

While the intent with the Microsoft Ignite session and this blog series was to provide 5 tips for running IIS workloads on Windows containers, we could not leave this one out – so here’s a bonus blog post for you!

Many times when containerizing an existing application with Windows containers, you’ll get caught on the process of writing a Docker file, to then build a container image, to then run a new container, to then test if the application work… and if it fails, you have to start all over: re-write your Docker file, then build a container image, then run a new container, then test if the application work. Depending on how complex your application is structured, this will be a tedious process.

 

To solve that, sometimes all you need is to open the IIS MMC console and check how the configuration of your website is showing up. However, the IIS remote management is not available on Windows containers. Since this is just an additional feature, all you have to do is to enable it.

 

Before we get started though, keep in mind this is something you can use while developing/testing your application. This should not be used in production.

 

First things first, creating a new user account

Prior to configuring IIS remote management, you need to figure out how you’re going to remote manage the container instance. Keep in mind Windows containers are not domain-joined and by default have two local user accounts: ContainerUser and ContainerAdmin. Both accounts are for interactive use, not remote management. Because of that, you need to create a new user account, either interactive or on your Docker file. Here's how you can create a new user account on PowerShell:

net user <username> "<password>" /ADD

Additionally, you need to provide the user the proper privilege. Since this should only be used on test environments, the easier way is to add it to the local Administrator group:

net localgroup administrators <username> /add

 

Enable IIS remote management

By default, IIS remote management is disabled. To enable it, you can use the Install-WindowsFeature command and configure it using a registry key. Finally, we ensure the service is set to Automatic so it will run on any container instance:

Install-WindowsFeature Web-Mgmt-Service Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\WebManagement\Server -Name EnableRemoteManagement -Value 1 Set-Service WMSVC -StartupType Automatic

 

Configure IIS remote management as part of your Docker file

The options above work if you are configuring a running container instance. If you’re going to build a container image to then test your application, you can add these instructions on a Docker file. Here’s an example:

# escape=` FROM mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2022 RUN powershell.exe -command ` net user <username> "<password>" /ADD; ` net localgroup administrators <username> /add RUN powershell.exe -command ` Install-WindowsFeature Web-Mgmt-Service; ` Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\WebManagement\Server -Name EnableRemoteManagement -Value 1; ` Set-Service WMSVC -StartupType Automatic

I have used some best practices on the Docker file above, such as combining PowerShell commands on a single RUN for smaller container images and using backtick for escaping directives (basically telling the Docker file that the command continues on the next line).

 

To create a new image based on this Docker file, you can use:

docker build -t iisremote:v1 .

 

Accessing the container instance

Now that you have a container image, you can run a container based off it:

docker run -d -p 8080:80 -p 8172:8172 iisremote:v1

The command above will run a new container based on the image we created previously. Notice the ports that I’m opening: I’m mapping port 8080 to port 80 from the container, which is where IIS is listening for the application. The other port that was mapped is 8172, which is the default port for IIS remote management. Let’s check for the container IP address so we can access it:

docker ps docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <container-ID>

Now you can open the IIS MMC console on your machine and target the corresponding container IP address:

IISRemote01.png

You’ll be asked to provide the credentials to access the remote server/container. These are the same credentials we created earlier. Once you’re done, you can give the connection a name and click Finish to access it:

IISRemote02.png

 

Conclusion

While not recommended for production scenarios, accessing the IIS MMC console is a great way to troubleshoot and validate web applications that are being containerized. You must configure a user account to access it remote and enable the IIS Remote Management feature, and once you do that, you can access the IIS instance on the container from an IIS MMC console on another machine.

I hope this final blog post helps you in the process of testing and validating your IIS web application. Don’t forget to check out the other blog posts on this series:

#1 SSL certificate lifecycle management

#2 IIS App Pools and Websites

#3 Hardcoded configuration

#4 Horizontal Scale

#5 Container and Node OS upgrade

 

Let us know what you think about all of these in the comments section below!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.