Announcing a New Windows Server Container Image Preview

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

Today we are very pleased to announce a new Windows Server base OS container image preview built from Windows Server 2022 with Desktop Experience. To try it out, on a Windows Server 2022 Insider Build 20344 as the container host, run this command to start:

docker pull mcr.microsoft.com/windows/server/insider:10.0.20344.1

The direct link of the image repo on Docker Hub is here https://hub.docker.com/_/microsoft-windows-server-insider/.  

Why did we build this new image?

There are 3 Windows Base OS container images today that nicely cover the broad spectrum of customer needs: Nano Server – ultralight, modern Windows offering for new app development; Server Core – medium size, best fit for Lift and Shift Windows Server apps; Windows – largest size, almost full Windows API support for special workloads. Nano Server and Server Core container image adoption has been steadily growing and widely used for a while. In the last year or so, we are also seeing uptake of the Windows image adoption. Meanwhile, in the Windows Container community on GitHub and through our Customer Support, we have received feedback regarding constraints when using that Windows base OS container image. For example,

• Windows server 2004 has IIS application pool connection limit of 10


• Windows Server Container – mcr.microsoft.com/windows should have been a Server OS Container

Some of the constraints are by design because that Windows container image is built from a full Windows Client edition and enabled to run on Windows Server. As we are committed to invest in the Windows containers business, we believe it is a right thing at this right time to build a new image based on a “full” Windows Server edition to enable more capabilities. “Full” in the sense that we choose to use the Windows Server 2022 with Desktop Experience edition. Some of you may refer this as “Server Core” + “Desktop UI” informally. That’s how this new container image was born and built. It will be added to all the relevant repos on Microsoft Container Registry (MCR) and Docker Hub pages. I should note, though this image is built from an edition with Desktop Experience, Windows containers today by design do not have GUI. That’s not changed with this new image.  

What’s the name again?

Windows containers by themselves are not stand-alone products. They are considered features of Windows Server. Whatever name we choose needs to show that connection but also avoid potential confusion or duplication. That leaves us limited room for creativity . As you can see, with the path on MCR, “mcr.microsoft.com/windows/server”, this image is referred as “Windows Server base OS image”, or just short like this, “Server base image”, or “Server image”.

What about this new image?

This new image will be available with Windows Server 2022 release only. For those of you who are using the Windows images from previous releases that are still in support such as Windows Server SAC v1809, SAC v1909, SAC v2004 and SAC v20H2, those images are not changed and have their respective support cycles. This new image is not available with those previous releases. We encourage you to adopt Windows Server 2022 and move to use this new Server image.

Here is a quick comparison between all the 4 images:

Note: 

* “Supported Version today” lists the Windows Server releases that the container image was or will be released and is or will be supported. For example, with the first row, it means, Nano Server image was released with Windows Server SAC v1809, v1909, v2004 and v20H2 releases and will be in Windows Server 2022 release. That list can change as some releases reach their end of support.

**In the release wave of Windows Server 2019 and SAC v1809, Nano Server container and Windows container images were only shipped as an SAC with 18 months support cycle. Based on customer feedback, last year we have extended Nano Server container in the SAC v1809 release to be supported for 5 years. This Windows container image currently will reach its end-of-life support (EOL) in May hence we will be sure to share the update on the extension in May before the EOL. On the other hand, Server Core container image in that release wave was shipped both as an LTSC and an SAC. In an oversimplified way, you can think all the 3 images released during Windows Server 2019 and SAC v1809 wave are now being made aligned to be supported for 5 years to Jan 2024. We understand this is a confusing topic. We’ll come back with details in future blogs.

What are the key benefits and capabilities of the new image?

Compared to the current Windows image:

• Size Smaller: slightly smaller, from 3.4GB down to 3.1GB.


• Performance and Reliability Improved: Over the years we have improved performance and reliability of the Server Core container images thanks to the large adoption internally and externally. This image inherits all the improvements from Server Core.


• LTSC Support from the get-go: we are planning to support this image as an LTSC with 5 years mainstream support.


• Server functionality: we are still validating so the list here is not complete but we expect this image will enable more Server scenarios/features.
  
  
  
  • IIS Connection: as mentioned earlier, there was a 10 connection limit. This new image should no longer have this limit. We have customers validating with their scenarios.
  
  
  • Web APIs e.g. Web Management Services (WMSVC): in that same GitHub issue related to IIS, it was reported this feature is not supported. We are yet to validate but we believe this should be supported.         
  
  
  
  


• Fuller API support
  
  
  
  • GPU Support: We announced GPU support back in April 2019 in this blog Bringing GPU acceleration to Windows containers, with this accomplishing GitHub page on setting up the demo: Virtualization-Documentation/windows-container-samples/directx at live . We are very glad to share GPU support is validated on this new image. Below is a screenshot:
  
  
  
  

OK, that’s interesting. How do I get started?

Step 1: Install a Windows Server 2022 Insider

To get started, you’ll need a Windows Server 2022 installation based on the Insiders preview build 20344. You can download the bits from the Insiders page here: Download Windows Server Insider Preview. Once you download the ISO (or VHD), create a new VM based on this image.

Step 2: Install Docker

Once you have a working Windows Server 2022 Preview deployment, follow this to install Docker:

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force

Install-Package -Name docker -ProviderName DockerMsftProvider

Restart-Computer -Force

Once the machine is restarted, run ‘docker info’ to ensure Docker was correctly installed.

Step 3: Pull the new image

docker pull mcr.microsoft.com/windows/server/insider:10.0.20344.1

Step 4: Run the new image

docker run -it mcr.microsoft.com/windows/server/insider:10.0.20344.1 cmd

Here is a screenshot for your reference:

Note:

• On a Windows Server host, containers are by default run in the process-isolation mode. You can find more at this doc page Windows Server Container Isolation Modes.


• If you would like to try out on a Windows 10 machine, please follow the instructions here Use Containers with Windows Insider Program. Be sure to use the latest Insider release. For example, I used a Windows 10 21364 Insider build. On a Windows 10 host, containers are by default run in the Hyper-V isolation mode.

References:

• Use Windows containers with the Windows Insider Program


• Windows Server Insiders Community on Tech Community


• Windows Container community on GitHub


• Windows Server Base OS Image Insider Build on Docker Hub

Closing

It’s been such a great journey since we started working on making this new image early this year. Your feedback really propelled us on the direction and innovations. We are so excited to share this with the community. We may get it right or we may get it wrong. Fail fast if needed. But we are in !

As always, we love to see you try it out, and give us feedback. You can share your feedback at our GitHub community, or contact us directly.

Weijuan

Twitter: @WeijuanLand

Email: win-containers@microsoft.com

Finding process which sporadically locks the workstation

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

Hi all,

A customer of mine recently reported an issue that some workstations sporadically lock while the user is working and asked if we could figure out the culprit. Here is the story.

First let me mention that Konstantin Chernyi, a Microsoft CE colleague from Russia, contributed greatly here. So credits also go to him (thanks, Konstantin).

Before we start you need to understand a few basics. A workstation is usually locked by calling the User32.dll function User32dll!LockWorkStation (https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-lockworkstation). There may be other options but most applications rely on this function. LockWorkStation creates the LogonUI.exe process to display the Logon Screen and the Lock Screen (if configured). It’s also important to know the Lock events can be traced using the Microsoft-Windows-WinLogon provider. You can get a list of all installed providers by running the command

XPerf.exe -providers i

XPerf is a good choice to narrow down this type of sporadic issue. It supports circular file mode, which means it can overwrite old events to keep the file size at a specified maximum (important for long runs). It can also capture the stack to support stackwalking, so we can see functions that processes call (if symbols are loaded). XPerf is part of the Windows Performance Toolkit, which in turn is part of the Windows Assessment and Deployment Kit (Windows ADK). You can download the ADK here: https://docs.microsoft.com/en-us/windows-hardware/get-started/adk-install.

In Windows 10, Windows Performance Recorder (wpr.exe) is built-in and could be an alternative to XPerf (https://docs.microsoft.com/en-us/windows-hardware/test/wpt/author-a-custom-recording-profile). In this blog, however, I’m going with XPerf.

1. Create the trace

I asked the customer to run the following command in an elevated command prompt on a client that was affected by the sporadic locks:

xperf -on proc_thread+loader+profile+interrupt+dpc+dispatcher+cswitch -stackwalk profile+cswitch+readythread -buffersize 1024 -minbuffers 256 -maxbuffers 256 -maxfile 256 -filemode circular -start wl -on microsoft-windows-winlogon -buffersize 1024 -minbuffers 256 -maxbuffers 256 -maxfile 32 -filemode circular

This starts two ETW sessions: A kernel trace with some kernel providers to capture process and thread creation, image load and unload events, CPU samples, and the stack. The output file should stay at 256 MB (-maxfile, -filemode circular). The second trace captures events of the Microsoft-Windows-WinLogon provider which includes the Lock event.

After that the customer created a scheduled task, which triggers on the lock workstation event (luckily, we have this predefined trigger) with a delay of 3 seconds. This task runs the command to stop the trace and merge the trace files.

XPerf -stop -stop wl -d %TEMP%Lock.etl

Note that the two subsequent “-stop” are not a mistake. Remember that we created two ETW sessions?

2. Analyze the trace

To open the Lock.etl file, I use Windows Performance Analyzer (WPA).  I originally worked with the Lock.etl file uploaded by the customer, but for this blog post I simulated this issue to avoid posting screenshots with customer data. The simulation was done by calling RunDLL32.exe User32.dll,LockWorkStation, which makes RunDLL32.exe the “evil” process.

In WPA, I started with the Generic Events graph. Here we can find the event providers we traced next to the kernel trace (in our case the Microsoft-Windows-Winlogon provider).

Taking a closer look, we can see that the Lock event is also part of the trace (Yeah, we caught the fish).  Now, as we learned earlier, we know that a workstation lock triggers the LogonUI.exe process so I tried to find the start of this process in WPA.  For this, I needed another graph: Lifetime by Process.

The image shows the LoginUI.exe process in the timeline. The call to the LockWorkStation function must have happened shortly before the LogonUI.exe process was created. To get rid of unnecessary information we Zoom to the area starting at approx. 3 seconds before and ending about a second after the start of LogonUI.exe. I highlighted those 4 seconds in the graph, right-clicked in the highlighted section and selected “Zoom”.

Somewhere in this section the call to LockWorkStation happens. The “Transient” process list showed five processes were started within those 4 seconds. But it’s possible that a process started earlier than this zoomed-in-view made the call to User32!LockWorkStation. The processes started before the beginning of the zoomed area, are grouped into the “Permanent” Lifetime.

To finally find the caller to LockWorkStation I need to search the stack of all running processes (Permanent and Transient) for the expression LockWorkStation. To do this, I added another graph to view the stack: CPU Usage (Sampled). This new graph automatically adopts to the zoomed timeline and only displays processes running in those 4 seconds.

Now it’s time to load the debug symbols to. Otherwise we cannot search for the function name. I made sure that my PC had an Internet connection and, in the menu bar of the Windows Performance Analyzer, I clicked Trace -> Load Symbols. It could take a while when symbols are first loaded. 

I highlighted the first line of the process table in the CPU Usage (Sampled) graph (to make sure to search all processes) and clicked on the small magnifier icon to open the search dialog. After that I clicked the three dots to expand the dialog and typed “LockWorkStation” into the field after “contains” (the query is constructed automatically so this box can be left empty).

Clicking “Find All” unmasked our culprit.

Rundll32.exe was quickly identified as the calling process. Handcuffs, conduct under escort. Case closed.

CLI for Microsoft 365 v3.9

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

CLI for Microsoft 365

Manage Microsoft 365 and SharePoint Framework projects on any platform

New version of CLI for Microsoft 365 – v3.9

m365 spfx project upgrade –preview

m365 aad app add –manifest @manifest.json

m365 spo site get --url https://contoso.sharepoint.com/sites/contoso

m365 spo site get --url /sites/contoso

m365 spo set --url https://contoso.sharepoint.com

m365 aad app role add --appName "My app" --name Managers --description "Managers" --allowedMembers usersGroups --claim managers

m365 planner plan add --title "My Planner Plan" --ownerGroupName "My Planner Group"

m365 spo site apppermission add –siteUrl https://contoso.sharepoint.com/sites/project-x –permission read –appDisplayName Foo

m365 spo userprofile get --userName 'john.doe@mytenant.onmicrosoft.com'

m365 viva connections app create --portalUrl https://contoso.sharepoint.com --appName Contoso --description "Contoso company app" --longDescription "Stay on top of what's happening at Contoso" --companyName Contoso --companyWebsiteUrl https://contoso.com --coloredIconPath icon-color.png --outlineIconPath icon-outline.png

m365 teams app publish --filePath ./contoso.zip

npm i -g @pnp/cli-microsoft365

docker run --rm -it m365pnp/cli-microsoft365:latest

Power Virtual Agents bot setting the Out Of Office

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

It is always interesting to hit the wall with limitations when you are working with Power Automate. Some limits are due to licensing but some are due to other good reasons. I was running a PoC where a person interacting with a Power Virtual Agent bot required to do actions on behalf of that person. And after digging some information out (Thank you @Tomasz for helping there! ) it was clear that I had reached the wall when I was trying to make my little bot to set up Out of Office for the interacting user. Using the Office 365 Set Automatic Replies action always works on the connection user only. And since you can not act on behalf of that user it required to go beyond the wall and say “there is no spoon”. And I found it there wasn’t a spoon- just the miracle world of Graph API.

From that phase I advanced to create

• Azure Logic Apps that uses Graph API to set the Out of Office / Automatic replies to a specific user.


• Setting up a Azure API Management service so that Azure Logic App can be called from the Cloud Flow running inside Power Virtual Agent – and still keep on using standard licensing (no need to go to premium)

First it was necessary to create the Azure App Registration (applicationid, secret) with suitable set of API permissions. After that it was all about figuring out the Graph API call & JSON to set the Automatic Reply / Out of Office. Read the documentation (& about permissions) from Docs here.

Next I built a Azure Logic Apps that uses HTTP Request trigger (get) to retrieve user email and number of away days in parameters.

This is the format to exclude parameters from the GET request. triggerOutputs()[‘queries’][‘FileID’]

After those steps I have user email and number of days that needs to be set Out of Office. I returned the HTTP-request and prepared variables with Application ID, TenantID and App Secret information to be able to call Graph API with application permissions.

The key is of course setting the Out of Office information JSON.

The Graph API call URL and example JSON I used to test this are:

https://graph.microsoft.com/v1.0/users/useremail/mailboxsettings
 
{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#Me/mailboxSettings",
     "automaticRepliesSetting": {
     "externalAudience": "all",
      "externalReplyMessage": "I am away from the office. ",
      "internalReplyMessage": "I am away from the office. ",
      "status": "Scheduled",
      "scheduledStartDateTime": {
          "dateTime": "2021-04-17T18:00:00.0000000",
          "timeZone": "UTC"
        },
       "scheduledEndDateTime": {
          "dateTime": "2021-04-18T18:00:00.0000000",
          "timeZone": "UTC"
        }
  }
}

Then it was just the case of patching the information

The next step was to create the Azure API Management Service and define the API call there. There are two ways to handle the information transportation: in the body (as JSON) or as parameters. I put the Username and Days in this Proof of Concept to parameters.

For how to create and set up Azure API Management you can find information in this URL. It is good to keep in mind that Azure API Management has a cost involved – it is not a free one. I created the one with Developer (No SLA) tier to keep costs lower. And it still estimated to be over 40€ per month. For production use the price will be higher.

Another alternative would have been to put the “set these to Out of Office” information to a SharePoint List (for example) and use a Azure Logic Apps trigger to read that list and make those API Calls. That would have some delay, but since Out of Office is rarely requiring an instant response it would be a better one for the real world scenario in this case. However if you are already using Azure API management then using it for this as well is a good idea. But setting it up solely for a single purpose does not get a good ROI for most cases.

After setting the API up into the Azure you can export it directly to the Dataverse for Teams environment – so it is there for the bot to use without any Premium licensing.

When adding an action to your Cloud Flow in the Dataverse for Teams environment where your bot runs you can find the custom action in the menu.

Cool – what about the test-run side?

And when running this one from the PVA of the acting user I can see the results via Teams easily

There are of course other steps as well in that PoC conversation & flow but setting up the Out of Office proved to require a bit more steps than I originally thought. I have to say that this was also a great learning experience about updating user mailbox settings via Graph API and as well about using Azure API management to create a custom connector to Power Automate.

With Azure API Management & Graph API you can quite easily go beyond the walls what you have with Dataverse for Teams bots and applications.

This article is a repost of my blog post in my own blog at MyTeamsDay.Com.

Scaling with Azure

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

In today’s world we must be able to scale our workloads, whether that be dealing with an internal workload or an external workload serving your organisations’ customers.  There are lots of options available to you to implement that scale and deal with the traffic to your workload, let’s walk through some of the options within Azure and help you understand their use cases.

Azure Load Balancer

The Azure Load Balancer is one of the first options that you have to help deal with scaling your workload.  It supports TCP/UDP based protocols such as HTTP, HTTPS and SMTP and other protocols used within real-time voice and video messaging applications. It helps you distribute traffic to your backend virtual machines and is a fully managed service.

With the load balancer you can distribute traffic either from external traffic or for internal traffic.  The Azure Load balancer works on Layer 4 of the OSI model and is a transparent load balancer.  Meaning it won’t do anything to the packets that it receives and just sends to them onto the endpoint should depend on the routing algorithm.  The Azure Load Balancer has a lot of features, one that I love is the outbound connection feature, which allows you to configure all outbound traffic from your virtual network to the Internet to be displayed as from the frontend IP of the load balancer.

Azure Application Gateway

The Azure Application Gateway is an HTTP or HTTPs load balancer and behaves differently to the networking load balancer.  It will take the connection coming into it, terminate and start a new connection to the backend endpoint based on its routing algorithms.  This opens new possibilities such as redirections or URL rewrites or header changes. 

Two of my favourite features of the Azure Application Gateway are connection draining and autoscaling.  Both help give you confidence of running your environment and help save on operational costs.

With connection draining it helps you to gracefully remove backend endpoints to carry out planned maintenance or upgrades.   With autoscaling it can start to scale out or in based on the traffic pattern to your Application Gateway.  This not only helps to eliminate the guessing game of over provisioning workloads and helps to avoid your operations teams having to manually scale out or in when traffic spikes.

Azure Traffic Manager

The Azure Traffic Manager is a DNS-based load balancer, it allows you to distribute traffic across your public facing applications.  With the traffic manager it will use DNS to direct requests from your users to the appropriate endpoint based on the traffic-routing method that you have configured.  Your endpoints can be any Internet-facing service hosted inside OR outside of Azure.

With Traffic Manager you can help to provide great performance to your end users with distributed endpoints through out the globe.  The features that I really enjoy is the Real User Measurements and Traffic View features.  They can be used to give you a real insight into where your users are based and the performance they are experiencing.  And the data that is collected can really help you make informed decisions on how to develop your application in the future.

Azure Front Door

Azure Front Door works at Layer 7 of the OSI model and based on your routing method you can ensure that your customer is routed to the fastest and most available endpoint on offer. Like Traffic Manager, Front Door is resilient to failures, including failures to an entire Azure region.  With Front Door you can offload SSL and certificate management, define a custom domain, and provide application security with integrated Web Application Firewall (WAF), with a ton of other features as well.

Your end points can be based within Azure or elsewhere. No matter where or what your endpoints are Front Door will help provide the best experience for your end user.

Azure DDoS Protection Basic is integrated into the Front Door platform by default and helps to defend against the most common and frequently occurring Layer 7 DNS query floods and layer 3 and 4 volumetric attacks that target public endpoints.

Azure Web Application Firewall

Azure Web Application Firewall (WAF) can also be used to protect your Front Door and Application Gateway implementations.  Because the WAF policies are “global resources” you can apply the same policy to your Front Door and Application Gateway implementations and have a consistent approach to prevention and detection.

Which one?

There are times when it’s not a question of which one should I use, as there are scenarios when you would use two of these options together to provide the best experience all round.  In preview there is a feature within the Azure Portal where it will walk you through some questions and give some advice on the best options for you – Load Balancing – help me choose.

Each of the load balancer have unique features and unique use cases, and as I said can often be used in combination together.  For examples of how to use them in different scenarios be sure to check out the Azure Architecture Centre for reference architecture diagrams to get your imagination sparked!

Microsegmentation with Azure Stack HCI

by Contributed | Apr 28, 2021 | Technology

This article is contributed. See the original author and article here.

Have you deployed multiple applications in your HCI cluster? Do you have application workloads in your cluster that need access to the Internet? Do you have remote users accessing application workloads in your HCI cluster? If the answer to any of these questions is yes, please read on to find out how you can protect your workloads from unauthorized access and cyber-attacks (Internal or External).

Problem: Need for network security and issues with traditional approaches

Network security is a top concern for organizations today. We are faced with increasing breaches, threats, and cyber risk. Cyber criminals are targeting high business impact data with sophisticated attacks designed to bypass perimeter controls. Once inside the company network, attackers are free to move from one system to another, in search of sensitive or personally identifiable information. These breaches can go unnoticed for a long time.

Network segmentation has been around for a long time to isolate high value data and systems. In traditional networks, security is set at the edge, where North-south communication takes place (interactions that are travelling in and out of the datacenter). This secures intranet from outside world. But offers little protection in the modern hybrid cloud world, where the perimeter has all but evaporated and a large portion of the traffic flows east-west, or server to server, between applications.

If you look at the topology below, end points can communicate with each other freely within VLANs or subnets behind a firewall. Infections on one of these servers are not contained and can easily spread to other servers.

Organizations may use physical firewalls to protect east west traffic. But that has its own drawbacks. Significant network resource utilization bottlenecks are created by sending east-west communication through a physical firewall. If firewall capacity is exhausted, security can be scaled by replacing with larger firewall or adding additional physical firewall, which is cumbersome and expensive.

Moreover, the use of physical firewalls can also create additional latency for certain applications. All traffic must traverse a physical firewall to be segmented, even when residing on the same physical server.

Solution: Microsegmentation in Azure Stack HCI

The ideal solution to complete protection is to protect every traffic flow inside the data center with a firewall, allowing only the flows required for applications to function. This is the Zero Trust Model.

Microsegmentation is the concept of creating granular network policies between applications and services. This essentially reduces the security perimeter to a fence around each application or virtual machine. The fence can permit only necessary communication between application tiers or other logical boundaries, thus making it exceedingly difficult for cyber threats to spread laterally from one system to another. Logical boundaries can be completely custom. They can be your different environments: Dev, Test, Production. Or different types of applications, or different tiers within an application. This securely isolates networks from each other and reduces the total attack surface of a network security incident.

With Azure Stack HCI, you can define granular segmentation for your applications and workloads and protect them from both external and internal attacks. This is achieved through a distributed firewall, enabling administrators to define access control lists to restrict access for workloads attached to traditional VLAN networks and overlay networks. This is a network layer firewall, allowing or restricting access based on source and destination IP addresses, source and destination ports and network protocol. You can read more about this here.

IMPORTANT: The microsegmentation policies can be applied to all Azure Stack HCI workloads attached to traditional VLAN networks.

The firewall policies are configured through the management plane. You have multiple options here – standard REST interface, Powershell, Windows Admin Center (WAC) and System Center Virtual Machine Manager (SCVMM). The management plane sends the policies to a centralized control plane, Network Controller. This ships as a Server role in Azure Stack HCI OS. Network Controller pushes the policies to all the applicable Hyper-V hosts, and the policies are plumbed at the vSwitch port of virtual machines. Network Controller also ensures that the policies stay in sync, and any drift is remediated.

Configure and manage microsegmentation in Azure Stack HCI

There are two high level steps to configure microsegmentation for HCI. First, you need to setup the Network Controller and then, configure microsegmentation policies.

Setup Network Controller

Network Controller can be setup using SDN Express Powershell scripts or the Windows Admin Center (WAC) or through System Center Virtual Machine Manager (SCVMM).

Windows Admin Center

If you are deploying HCI for the first time, you can use the Windows Admin Center deployment wizard to setup Network Controller. SDN deployment is Step 5 of the wizard. This deploys the Network Controller component of SDN. Detailed instructions for launching this wizard, setting up the HCI cluster and setting up Network Controller is provided here.  In the default case, you need to provide only two pieces of input:

1. Path to the Azure Stack HCI OS vhdx file. This is used to deploy the Network Controller VMs.


2. Credentials to join the Network Controller VMs to the domain and local admin credentials.

If you do not have DHCP configured on your management network, you will need to provide static IP addresses for the Network Controller VMs. A demo of the SDN setup is provided below:

SDN Express Scripts

If you already have an existing HCI cluster, you cannot deploy SDN through Windows Admin Center today. This support is coming soon.

In this case, you can deploy Network Controller (NC) component of SDN using SDN Express scripts. The scripts are available in the official Microsoft SDN github repository. The scripts need to be downloaded and executed on a machine which has access to the HCI cluster management network. Detailed instructions for executing the script are provided here.

The script takes a configuration file as input. Template file can be found in the github repository here. You will need the provide/change the following parameters to setup Network Controller for microsegmentation on traditional HCI VLAN networks:

1. VHDPath: VHDX file path used by NC VMs. Script must have access to this file path.


2. VHDFile: VHDX file name used by NC VMs.


3. JoinDomain: domain to which NC VMs are joined.


4. Management network details (ManagementSubnet, ManagementGateway, ManagementDNS, ManagementVLANID): This is the management network of the HCI cluster.


5. DomainJoinUsername: Username to join NC VMs to the domain


6. LocalAdminDomainUser: Domain user for NC VMs who is also local admin on the NC VMs


7. RestName: DNS name used by management clients (such as Windows Admin Center) to communicate with NC


8. Details of NC VMs (ComputerName, HostName, ManagementIP, MACAddress): Name of NC VMs, Host name of Server where NC VMs are located, management network IP Address of NC VMs, MAC address of NC VMs


9. HyperVhosts: Host server names in the HCI cluster


10. NCUserName: NC Administrator account. Should have permission to do everything needed by someone administering the NC (primarily configuration and remoting). Usually, this can be same as LocalAdminDomainUser account.

Some other important points:

1. The parameters VMLocation, SDNMacPoolStart, SDNMacPoolEnd can use default values.


2. The following sections should be blank: Muxes, Gateways (Muxes = @())


3. If you are deploying microsegmentation for VLAN networks, you should keep the PA network details section blank. Otherwise, if you are deploying overlay networks, please fill in that section.


4. Rest of the parameters below the PA network section can be commented out.

A sample file is shown below:

Configure Microsegmentation Policies

Once Network Controller is setup, you can go ahead and deploy your microsegmentation policies.

1. The first step is to create a logical network for your workloads hosted on VLAN networks. This is documented here.


2. Next, you need to create the security ACL rules that you want to apply to your workloads. This is documented here.


3. Once the ACL rules have been created, you can apply them to the network or a network interface.
   
   
   
   1. For applying ACLs to a traditional VLAN network, see instructions here.
   
   
   2. For applying ACLs to a virtual network, see instructions here.
   
   
   3. For applying ACLs to a network interface, see instructions here.
   
   
   
   

After the ACL rules have been applied to the network, all virtual machines in that network will get the policies and will have restricted access based on the rules. If the ACL rule has been applied to a network interface, the network interface will get the policies and will have restricted access based on the rules.

So, as you can see, with microsegmentation, you can protect every traffic flow in your HCI cluster, allowing only the flows required for your applications to function. Please try this out and give us feedback at sdn_feedback@microsoft.com. Feel free to reach out for any questions as well.