 Hi, my name is Grisher Hernandez from the Hybrid Platforms Business Unit over at Red Hat. In this brief demonstration, I'm going to be going over Windows Container Support for Red Hat OpenShift Container Platform. The process of installing Windows Container Support for Red Hat OpenShift is the same whether you're running on a hyperscaler or on vSphere. First, you need to create the install config.yaml file by running OpenShift install create install config. This will take you through the installation wizard where you'll provide information about your platform and it will also prompt you for your pull secret. Once the install-config.yaml file is created, go ahead and edit this file and change the networking type from OpenShift SDN to OVN Kubernetes. The next step is to create your manifest files. To create the manifest, run OpenShift install create manifest. You'll be creating a new configuration in the manifest directory, calling it cluster-network03config.yaml. The configuration can be found on docs.openshift.com. Two important things about this configuration file. One, hybrid overlay networking is necessary and the IP range must not overlap any other IP ranges that you may have. Second, the hybrid overlay XV LAN port is only necessary if you're running on a vSphere. It must not be set for a hyperscaler. Once you've created this configuration file, run OpenShift install create cluster to begin the installation process. Once the install is completed, go ahead and export your kube config file as noted in the log output. Now you can verify that the OVN Kubernetes and hybrid overlay networking configurations were done. Inspect the network operator object and see that the OVN Kubernetes was indeed set, and also check to see that hybrid overlay network configuration was done. Next, you'll install Windows Machine Config operator. You can do this by visiting the operator hub by going in the UI on the left-hand side under operators, operator hub. In the search text field, type in Windows and select Windows Machine Config operator and then select install. The default should be fine for any installation. Make sure you tick the monitoring this namespace box and choose an update approval strategy. The installation will begin. Once the operator has been installed, go ahead and click on view operator. This will bring you to the Windows Machine Config operators overview page, which will give you information about how to further configure this operator. One of the prerequisites to spin up a Windows node is to upload an SSH key. This SSH key is used by the operator to set up and manage the Windows node. Go ahead and upload a private SSH key to the OpenShift Windows Machine Config operator as a secret. Once this secret has been uploaded, you're ready to set up a Windows node. The Windows node is set up the same way as the Linux node via machine set. A Windows machine set doesn't differ all that much from a Linux machine set. Here, you can see that it's labeled as the OSID of Windows, but it's also labeled as a worker, just like a Linux node. The only real difference is that the image used for this specific machine set is a Windows server image. To find out more information about how to set up a machine set specific to your hyperscaler, please visit docs.openshift.com. Once you set up your Windows machine set, go ahead and apply it using OC Apply. This will create two objects in OpenShift. This will create a machine set and a correlating machine. View the machine set by doing an OC Get Machine Set in the OpenShift Machine API namespace. To get the machines, do an OC Get Machine in the OpenShift Machine API namespace. As you can see, this is being provisioned and it will appear as a node in a few minutes. After a few minutes have passed, this Windows machine is now configured as a Windows node. To select this node, run an OCGetNodes-L Kubernetes.IO-OS equals Windows. Running the same command with a dash O wide will show you more information about this node. For example, that it's running Windows Server 2019 data center. By default, the operator will taint this Windows node so that no other workloads can run on it. To view the taint, run OCDescribeNode, the name of the node, and grip for taint. As you see, the taint is set as OS equals Windows colon node schedule. Running a containerized Windows workload is the same as running a containerized Linux workload with a few key differences. First, the workload must tolerate the taint that is set by the operator. Next, the image used for this workload must match the version of Windows Server that you're running. And finally, to help with scheduling, setting a node selector helps. Once you create this workload, this will go through the same process as a Linux workload. It will go through the same Kubernetes schedule and it will tolerate the taint. Go ahead and run a watch on your OCGetPods against the namespace you created your workloads to wait for your application to run. After a couple minutes, your application should be up and running. You interact with your containerized Windows workload the same way as you would interact with any other workload on OpenShift. For instance, you can verify that this containerized workload is running on the Windows node by doing an OCGetPods with the dash O wide while selecting the node specific to Windows. This containerized workload can also be accessed the same way a containerized Linux workload. For instance, you can grab the service and expose it running OCExposeSVC and the name of the service to create an OpenShift route. This OpenShift route will create a front end that will serve the north to south traffic. I hope you enjoyed this brief demonstration on Windows container support for Red Hat OpenShift and invite you to try it yourself. Thank you.