Mobilize your workloads with software-defined networking

<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" > <channel> <title>Networking Blog</title> <atom:link href="https://blogs.technet.microsoft.com/networking/feed/" rel="self" type="application/rss+xml" /> <link>https://blogs.technet.microsoft.com/networking</link> <description>Windows Networking support team and Product team blog</description> <lastBuildDate>Fri, 19 May 2017 20:48:25 +0000</lastBuildDate> <language>en-US</language> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <item> <title>Troubleshooting certificate issues in Software Defined Networking (SDN)</title> <link>https://blogs.technet.microsoft.com/networking/2017/05/19/troubleshooting-certificate-issues-in-software-defined-networking-sdn/</link> <comments>https://blogs.technet.microsoft.com/networking/2017/05/19/troubleshooting-certificate-issues-in-software-defined-networking-sdn/#respond</comments> <pubDate>Fri, 19 May 2017 20:47:33 +0000</pubDate> <dc:creator><![CDATA[AnirbanPaul]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[certificates]]></category> <category><![CDATA[Network Controller]]></category> <category><![CDATA[SDN]]></category> <category><![CDATA[security]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3985</guid> <description><![CDATA[As you may be aware, Network Controller in Windows Server 2016 uses certificate based authentication for communicating with Hyper-V hosts and Software Load Balancer MUX virtual machines (VMs). Some SDN customers have complained about communication issues between Network Controller and hosts, although certificates were correctly configured on both the entities. On debugging, we found that... <a aria-label="read more about Troubleshooting certificate issues in Software Defined Networking (SDN)" href="https://blogs.technet.microsoft.com/networking/2017/05/19/troubleshooting-certificate-issues-in-software-defined-networking-sdn/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p>As you may be aware, Network Controller in Windows Server 2016 uses certificate based authentication for communicating with Hyper-V hosts and Software Load Balancer MUX virtual machines (VMs).</p> <p>Some SDN customers have complained about communication issues between Network Controller and hosts, although certificates were correctly configured on both the entities.</p> <p>On debugging, we found that the customer had installed a non self-signed certificate into the computer&#8217;s <strong>Trusted Root Certification Authorities</strong> store. Although this certificate was not involved in communication between Network Controller and the hosts, the presence of such a certificate broke client authentication. Here is a view of some of the certificate properties:</p> <p>&nbsp;</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2017/05/dd.png"><img width="300" height="97" class="alignnone size-medium wp-image-3986" alt="dd" src="https://msdnshared.blob.core.windows.net/media/2017/05/dd-300x97.png" /></a></p> <p>The following Knowledge Base article provides information about this issue: <a href="https://support.microsoft.com/en-us/help/2802568/internet-information-services-iis-8-may-reject-client-certificate-requests-with-http-403.7-or-403.16-errors">Internet Information Services (IIS) 8 may reject client certificate requests with HTTP 403.7 or 403.16 errors</a></p> <p>To resolve this issue, you can uninstall the non self-signed certificate from the <strong>Trusted Root Certification Authorities</strong> certificate store for the Local Computer, or move the certificate to the <strong>Intermediate Certification Authorities</strong> store.</p> <p>One more thing to note is that that the <strong>Personal</strong> (My &#8211; cert:\localmachine\my) certificate store on the Hyper-V host must have exactly one X.509 certificate with Subject Name (CN) as the host FQDN. This certificate is used for communication with the Network Controller.</p> <p>This behavior is due to a bug in the system and will be fixed shortly. For now, please ensure that you have only one certificate with the Subject Name (CN) as the host FQDN.</p> <p>For more information, see the following topics in the Windows Server 2016 Technical Library.</p> <ul> <li><a href="https://docs.microsoft.com/en-us/windows-server/networking/sdn/security/nc-security">Network Controller Security</a></li> <li><a href="https://docs.microsoft.com/en-us/windows-server/networking/sdn/security/sdn-manage-certs">Managing certificates for Software Defined Networking</a></li> </ul> <p>Anirban Paul, Senior Program Manager</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/05/19/troubleshooting-certificate-issues-in-software-defined-networking-sdn/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Windows network performance suffering from bad buffering</title> <link>https://blogs.technet.microsoft.com/networking/2017/05/08/windows-network-performance-suffering-from-bad-buffering/</link> <comments>https://blogs.technet.microsoft.com/networking/2017/05/08/windows-network-performance-suffering-from-bad-buffering/#comments</comments> <pubDate>Mon, 08 May 2017 18:26:57 +0000</pubDate> <dc:creator><![CDATA[Daniel Mark Havey]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3945</guid> <description><![CDATA[Daniel Havey, Praveen Balasubramanian Windows telemetry results have indicated that a significant number of data connections are using the SO_RCVBUF and/or the SO_SNDBUF winsock options to statically allocate TCP buffers. There are many websites that recommend setting the TCP buffers with these options in order to improve TCP performance. This is a myth. Using Winsock... <a aria-label="read more about Windows network performance suffering from bad buffering" href="https://blogs.technet.microsoft.com/networking/2017/05/08/windows-network-performance-suffering-from-bad-buffering/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p>Daniel Havey, Praveen Balasubramanian</p> <p>Windows telemetry results have indicated that a significant number of data connections are using the SO_RCVBUF and/or the SO_SNDBUF winsock options to statically allocate TCP buffers. There are many websites that recommend setting the TCP buffers with these options in order to improve TCP performance. This is a myth. Using Winsock options (SO_RCVBUF and/or SO_SNDBUF) to statically allocate TCP buffers will not make Windows networking stack “faster”. In fact, static allocation of the TCP buffers will degrade performance in terms of how fast the connection responds (latency) and how much data it delivers (bandwidth). The Windows transports team officially recommends <strong>not</strong> doing this.</p> <p>TCP buffers need to be dynamically allocated in proportion to the Bandwidth Delay Product (BDP) of the TCP connection. There are two good reasons why we should let the Windows networking stack dynamically set the TCP buffers for us and not set them statically at the application layer. 1.) The application does not know the BDP (TCP does) so it cannot properly set the TCP buffers and 2.) Dynamic buffer management requires complex algorithmic control which TCP already has. In summary, Windows 10 has autotuning for TCP. Let the autotuning algorithm manage the TCP buffers.</p> <p><strong>Example:</strong> I am going to use the Cygwin application as an example since they recently fixed their buffering (thank you Corinna). The experiment is conducted across the Internet to an iperf server in France (from my desk in Redmond).</p> <h3><strong>Experiment 1 &#8212; Cygwin (Bad buffering):</strong></h3> <h6>Pinging 178.250.209.22 with 32 bytes of data:<br /> Reply from 178.250.209.22: bytes=32 time=176ms TTL=35<br /> Reply from 178.250.209.22: bytes=32 time=173ms TTL=35<br /> Reply from 178.250.209.22: bytes=32 time=173ms TTL=35<br /> Reply from 178.250.209.22: bytes=32 time=172ms TTL=35</h6> <h6>Ping statistics for 178.250.209.22:<br /> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),<br /> Approximate round trip times in milli-seconds:<br /> Minimum = 172ms, Maximum = 176ms, Average = 173ms<br /> &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;<br /> Client connecting to 178.250.209.22, TCP port 5001<br /> TCP window size: 208 KByte (default)<br /> &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;<br /> [ 3] local 10.137.196.108 port 56758 connected with 178.250.209.22 port 5001<br /> [ ID] Interval Transfer Bandwidth<br /> [ 3] 0.0- 1.0 sec 512 KBytes 4.19 Mbits/sec<br /> [ 3] 1.0- 2.0 sec 1.50 MBytes 12.6 Mbits/sec<br /> [ 3] 2.0- 3.0 sec 1.50 MBytes 12.6 Mbits/sec<br /> [ 3] 3.0- 4.0 sec 1.25 MBytes 10.5 Mbits/sec<br /> [ 3] 4.0- 5.0 sec 1.50 MBytes 12.6 Mbits/sec<br /> [ 3] 5.0- 6.0 sec 1.50 MBytes 12.6 Mbits/sec<br /> [ 3] 6.0- 7.0 sec 1.50 MBytes 12.6 Mbits/sec<br /> [ 3] 7.0- 8.0 sec 1.25 MBytes 10.5 Mbits/sec<br /> [ 3] 8.0- 9.0 sec 1.50 MBytes 12.6 Mbits/sec<br /> [ 3] 9.0-10.0 sec 1.50 MBytes 12.6 Mbits/sec<br /> [ 3] 0.0-10.1 sec 13.6 MBytes 11.3 Mbits/sec</h6> <p>&nbsp;</p> <p>We can see that the RTT is the same for both Experiment 1 &amp; 2 about 177ms. However, in Experiment 1 Cygwin has bad buffering and the throughput averages 11.3 Mbps and tops out at 12.6 Mbps. This is because in Experiment 1 Cygwin was using SO_RCVBUF to allocate 278,775 bytes for the TCP receive buffer and the throughput is buffer limited to 12.6 Mbps.</p> <h3><strong>Experiment 2 &#8212; Cygwin (Good buffering):</strong></h3> <h6>Pinging 178.250.209.22 with 32 bytes of data:<br /> Reply from 178.250.209.22: bytes=32 time=172ms TTL=35<br /> Reply from 178.250.209.22: bytes=32 time=172ms TTL=35<br /> Reply from 178.250.209.22: bytes=32 time=172ms TTL=35<br /> Reply from 178.250.209.22: bytes=32 time=173ms TTL=35</h6> <h6>Ping statistics for 178.250.209.22:<br /> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),<br /> Approximate round trip times in milli-seconds:<br /> Minimum = 172ms, Maximum = 173ms, Average = 172ms<br /> &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;<br /> Client connecting to 178.250.209.22, TCP port 5001<br /> TCP window size: 64.0 KByte (default)<br /> &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;<br /> [  3] local 10.137.196.108 port 56898 connected with 178.250.209.22 port 5001<br /> [ ID] Interval       Transfer     Bandwidth<br /> [  3]  0.0- 1.0 sec   768 KBytes  6.29 Mbits/sec<br /> [  3]  1.0- 2.0 sec  11.8 MBytes  98.6 Mbits/sec<br /> [  3]  2.0- 3.0 sec  18.0 MBytes   151 Mbits/sec<br /> [  3]  3.0- 4.0 sec  16.6 MBytes   139 Mbits/sec<br /> [  3]  4.0- 5.0 sec  16.4 MBytes   137 Mbits/sec<br /> [  3]  5.0- 6.0 sec  18.0 MBytes   151 Mbits/sec<br /> [  3]  6.0- 7.0 sec  18.0 MBytes   151 Mbits/sec<br /> [  3]  7.0- 8.0 sec  18.0 MBytes   151 Mbits/sec<br /> [  3]  8.0- 9.0 sec  15.6 MBytes   131 Mbits/sec<br /> [  3]  9.0-10.0 sec  17.4 MBytes   146 Mbits/sec<br /> [  3]  0.0-10.0 sec   151 MBytes   126 Mbits/sec</h6> <p>&nbsp;</p> <p>In Experiment 2 we see Cygwin perform without static application level buffering.  The average throughput is 126 Mbps and the maximum is 151 Mbps which is the true unloaded line speed of this connection.  By statically allocating the receive buffer using SO_RCVBUF we limited ourselves to a top speed of 12.6 Mbps.  By letting Windows TCP autotuning dynamically allocate the buffers we achieved the true unloaded line rate of 151 Mbps.  That is about an order of magnitude better performance.  Static allocation of TCP buffers at the app level is a bad idea.  <strong>Don’t do it</strong>.</p> <p>Sometimes there are corner cases where as a developer one might think that there is justifiable cause to statically allocate the TCP buffers.  Let’s take a look at three of the most common causes for thinking this:</p> <p>1.) Setting the buffers for performance sake.  <strong>Don’t.</strong>  TCP autotuning is a kernel level algorithm and can do a better job than any application layer algorithm.<br /> 2.) Setting the buffers because you are trying to rate limit traffic.  <strong>Be Careful!</strong>  The results may not be what you expect.  In the Cygwin example the connection is buffer limited to 12.6 Mbps maximum.  However, if the RTT were to change to about 40 ms then the connection would be limited to about 50 Mbps.  You cannot reliably set a bandwidth cap in this manner (See the BDP equations).<br /> 3.) Setting the buffers for some other reason.  Let’s have a discussion.  Please comment on the post and we will respond.</p> <p>&nbsp;</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/05/08/windows-network-performance-suffering-from-bad-buffering/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>Windows Networking for Kubernetes</title> <link>https://blogs.technet.microsoft.com/networking/2017/04/04/windows-networking-for-kubernetes/</link> <comments>https://blogs.technet.microsoft.com/networking/2017/04/04/windows-networking-for-kubernetes/#respond</comments> <pubDate>Tue, 04 Apr 2017 21:51:27 +0000</pubDate> <dc:creator><![CDATA[JMesser81]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3886</guid> <description><![CDATA[A seismic shift is happening in the way applications are developed and deployed as we move from traditional three-tier software models running in VMs to &#8220;containerized&#8221; applications and micro-services deployed across a cluster of compute resources. Networking is a critical component in any distributed system and often requires higher-level orchestration and policy management systems to... <a aria-label="read more about Windows Networking for Kubernetes" href="https://blogs.technet.microsoft.com/networking/2017/04/04/windows-networking-for-kubernetes/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p>A seismic shift is happening in the way applications are developed and deployed as we move from traditional three-tier software models running in VMs to &#8220;containerized&#8221; applications and micro-services deployed across a cluster of compute resources. Networking is a critical component in any distributed system and often requires higher-level orchestration and policy management systems to control IP address management (IPAM), routing, load-balancing, network security, and other advanced network policies. The Windows networking team is swiftly adding new features (<a href="https://blogs.technet.microsoft.com/virtualization/2017/02/09/overlay-network-driver-with-support-for-docker-swarm-mode-now-available-to-windows-insiders-on-windows-10/">Overlay networking and Docker Swarm Mode on Windows 10</a>) and working with the larger containers community (e.g. <a href="https://github.com/kubernetes/community/tree/master/sig-windows">Kubernetes sig-windows group</a>) by contributing to open source code and ensuring native networking support for any orchestrator, in any deployment environment, with any network topology.</p> <p>Today, I will be discussing how Kubernetes networking is implemented in Windows and managed by an extensible Host Networking Service (HNS) &#8211; which is used in both Azure Container Service (ACS) Windows worker nodes and on-premises deployments &#8211; to plumb network policy in the OS .</p> <p><em>Note: A video recording of the 4/4 #sig-windows meetup where I describe this is posted here: </em><a href="https://www.youtube.com/watch?v=P-D8x2DndIA&amp;t=6s&amp;list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4&amp;index=1"><em>https://www.youtube.com/watch?v=P-D8x2DndIA&amp;t=6s&amp;list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4&amp;index=1</em></a></p> <h1>Kubernetes Networking</h1> <p>Windows containers can be orchestrated using either <a href="https://docs.docker.com/engine/swarm/">Docker Swarm</a> or <a href="https://kubernetes.io/">Kubernetes </a><a href="https://docs.docker.com/engine/swarm/"></a><a href="https://kubernetes.io/"></a>to help &#8220;automate the deployment, scaling, and management of &#8216;containerized&#8217; applications&#8221;. However, the networking model used by these two systems is different.</p> <p>Kubernetes networking is built on the fundamental requirements listed <a href="https://kubernetes.io/docs/admin/networking/">here</a> and is either agnostic to the network fabric underneath or assumes a flat Layer-2 networking space where all containers and nodes can communicate with all other containers and nodes across a cluster <strong>without using NAT (encapsulation is permitted)</strong>. Windows can support these requirements using a few different networking modes exposed by HNS and working with external IPAM drivers and route configurations.</p> <p>The other large difference between Docker and Kubernetes networking is the scope at which IP assignment and resource allocation occurs. Docker assigns an IP address to every container whereas Kubernetes assigns IP addresses to a <a href="https://kubernetes.io/docs/user-guide/pods/">Pod</a> which represents a network namespace and could consist of multiple containers running inside the Pod. Windows also has a network namespace concept called a <strong><em>network compartment</em></strong> and a management surface is being built in Windows to allow for multiple containers in a Pod to communicate with each other through localhost.</p> <p>Connectivity between pods located on different nodes in a Kubernetes cluster can be accomplished either by using an overlay (e.g. vxlan) network or without an overlay by configuring routes and IPAM on the underlying (virtual) network fabric. Realizing this network model can be done through:</p> <ul> <li>CNI Network Plugin</li> <li>Implementing the &#8220;Routing&#8221; interface in Kubernetes code</li> <li>External configuration</li> </ul> <p>The sig-windows community (led by <a href="https://apprenda.com/">Apprenda</a>) did a lot of work to come up with an initial solution for getting Kubernetes networking to work on Windows. The networking teams at Microsoft are building on this work and continues to partner with the community to add support for the native Kubernetes networking model &#8211; <em>defined by the </em><a href="https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration"><em>Container Network Interface (CNI)</em></a><em> which, is different from the <a href="https://github.com/docker/libnetwork/blob/master/docs/design.md">Cloud Network Model (CNM) </a></em><a href="https://github.com/docker/libnetwork/blob/master/docs/design.md"></a><em>used by Docker</em> &#8211; and surfacing policy management capabilities through HNS.</p> <h2>Kubernetes networking in Azure Container Service (ACS)</h2> <p>Azure Container Service recently announced <a href="https://azure.microsoft.com/en-us/blog/kubernetes-now-generally-available-on-azure-container-service/">Kubernetes general availability</a> which uses a routable-vip approach (no overlay) to networking and configures <a href="https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview">User-Defined Routes (UDR)</a> in the Hyper-V (virtualization) host for Pod communication between Linux and Windows cluster node VMs. A /24 CIDR IP pool (routable between container host VMs) is allocated to each container host with one IP assigned per Pod (one container).</p> <p><img src="https://msdnshared.blob.core.windows.net/media/2017/04/UDR-in-ACS-Kubernetes-1024x576.png" alt="udr-in-acs-kubernetes" width="879" height="494" class="alignnone wp-image-3905 size-large" /></p> <p>With the recent Azure VNet for Containers announcement which includes support for a CNI network plugin used in Azure (pre-released here: <a href="https://github.com/Azure/azure-container-networking/releases/tag/v0.7">https://github.com/Azure/azure-container-networking/releases/tag/v0.7</a>), tenants can connect their ACS clusters (containers and hosts) directly to Azure Virtual Networks. This means that individual IPs from a tenant&#8217;s Azure VNet IP space will be assigned to Kubernetes nodes and pods in potentially the same subnet. The Windows networking team is also working to build a CNI plugin to support and extend container management through Kubernetes on Windows for on-premises deployments.</p> <h2>Kubernetes networking in Windows</h2> <p>Microsoft engineers across Windows and Azure product groups actively contributed code to the Kubernetes repo to enhance kube-proxy (used for DNS and service load-balancing) and kubelet (for Internet access) binaries which are installed on ACS Kubernetes Windows worker nodes. This overcame gaps <a href="http://blog.kubernetes.io/2016/12/windows-server-support-kubernetes.html">previously identified</a> so that both DNS and service load-balancing worked correctly without the need for Routing and Remote Access Services (RRAS) or netsh port proxy. In this implementation, the Windows network uses Kubernetes&#8217; default kubenet plugin without CNI plugin.</p> <p>Using HNS, one <em>transparent</em> and one <em>NAT</em> network is created on each Windows container host for inter-Pod and external communication respectively. Two container endpoints &#8211; connected to the Service and Pod networks &#8211; are required for each Windows container which will participate in the Kubernetes service. Static routes must be added to the running Windows containers themselves on the container endpoint attached to the service network.</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2017/04/Windows-Container-Host-ACS-Kubernetes.png"><img src="https://msdnshared.blob.core.windows.net/media/2017/04/Windows-Container-Host-ACS-Kubernetes-1024x576.png" alt="windows-container-host-acs-kubernetes" width="879" height="494" class="alignnone wp-image-3915 size-large" /></a></p> <p>In the absence of ACS-managed User-Defined Routes, Out-of-Band (OOB) configuration of these routes need to be realized in the Cloud Service Provider network, implemented using the &#8220;routing&#8221; interface of the Kubernetes cloud provider, or connected via overlay networks. Other solutions include using the HNS overlay network driver for inter-Pod communication or using the OVS Hyper-V switch extension with OVN Controller.</p> <p>Today, with the publicly available versions of Windows server and client you can deploy Kubernetes with the following restrictions:</p> <ul> <li>One container per Pod</li> <li>CNI Network Plugins are not supported</li> <li>Each container requires two container endpoints (vNICs) with IP routing manually plumbed</li> <li>Service IPs can only be associated with one Container Host and will not be load-balanced</li> <li>Policy specifications (e.g. network security) are not supported</li> </ul> <h1>What&#8217;s Coming Next?</h1> <p>Windows is moving to a faster release cadence such that new platform features will be made available in a matter of months rather than years. In some circumstances, early builds can be made available to Insiders as well as to TAP customers and EEAP partners for early feature validation.</p> <p>Stay tuned for new features which will be made available soon&#8230;</p> <h1>Summary</h1> <p>In this blog post, I described some of the nuances of the Kubernetes networking model and how it differs from the Docker networking model. I also talked about the code updates made by Microsoft engineering teams to the kubelet and kube-proxy binaries for Windows in open source repos to enable networking support. Finally, we ended with how Kubernetes networking is implemented in Windows today and the plans for how it will be implemented through a CNI plugin in the near future&#8230;</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/04/04/windows-networking-for-kubernetes/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Coming Soon: Transport Advancements in the Windows 10 Creators update</title> <link>https://blogs.technet.microsoft.com/networking/2017/03/27/coming-soon-transport-advancements-in-the-windows-10-creators-update/</link> <comments>https://blogs.technet.microsoft.com/networking/2017/03/27/coming-soon-transport-advancements-in-the-windows-10-creators-update/#comments</comments> <pubDate>Mon, 27 Mar 2017 17:17:03 +0000</pubDate> <dc:creator><![CDATA[Windows Networking Team [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3866</guid> <description><![CDATA[Windows 10 Creators update is coming soon along with an exciting array of new transport features.  Stay tuned for the official announcement!... <a aria-label="read more about Coming Soon: Transport Advancements in the Windows 10 Creators update" href="https://blogs.technet.microsoft.com/networking/2017/03/27/coming-soon-transport-advancements-in-the-windows-10-creators-update/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p>Windows 10 Creators update is coming soon along with an exciting array of new transport features.  Stay tuned for the official announcement!</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/03/27/coming-soon-transport-advancements-in-the-windows-10-creators-update/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>How to find the SDN gateway local address for BGP peering in Windows Server 2016</title> <link>https://blogs.technet.microsoft.com/networking/2017/03/23/how-to-find-the-sdn-gateway-local-address-for-bgp-peering-in-windows-server-2016/</link> <comments>https://blogs.technet.microsoft.com/networking/2017/03/23/how-to-find-the-sdn-gateway-local-address-for-bgp-peering-in-windows-server-2016/#respond</comments> <pubDate>Thu, 23 Mar 2017 16:17:24 +0000</pubDate> <dc:creator><![CDATA[AnirbanPaul]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[BGP]]></category> <category><![CDATA[Gateway]]></category> <category><![CDATA[RRAS]]></category> <category><![CDATA[SDN]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[Windows Server 2016]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3815</guid> <description><![CDATA[A few days back, I wrote a blog post about some issues being faced by Software Defined Networking (SDN) customers. The issue was specific to changing VPN bandwidth settings in Windows Server 2016. You can read more about that issue and the solution here. Another area where we have seen customers struggle is finding out the... <a aria-label="read more about How to find the SDN gateway local address for BGP peering in Windows Server 2016" href="https://blogs.technet.microsoft.com/networking/2017/03/23/how-to-find-the-sdn-gateway-local-address-for-bgp-peering-in-windows-server-2016/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p>A few days back, I wrote a blog post about some issues being faced by Software Defined Networking (SDN) customers. The issue was specific to changing VPN bandwidth settings in Windows Server 2016. You can read more about that issue and the solution <a href="https://blogs.technet.microsoft.com/networking/2017/03/06/troubleshoot-configuring-sdn-ras-gateway-vpn-bandwidth-settings-in-virtual-machine-manager/">here</a>.</p> <p>Another area where we have seen customers struggle is finding out the local SDN gateway server address. The local SDN gateway Server address is required for the following reasons:</p> <ol> <li>When you configure the remote VPN endpoint (in your enterprise or your local datacenter), you need to provide the local SDN gateway server address as the destination IP. This is the IP address advertised by the gateway for external connectivity</li> <li>If you are using BGP for learning dynamic routes over VPN, you will need the local SDN gateway server address to configure the BGP peering information. Note that this address will be different from the destination IP I have mentioned above, since this is the IP address of the internal interface of the VPN server.</li> </ol> <h2>Finding the external address of SDN gateway</h2> <p>This address will be used as the destination IP address when you configure the on-premise VPN server (or a GRE endpoint in the same datacenter). This address may be different for different tenants because the SDN gateway is a multi-tenant server.</p> <p>This address is displayed in the System Center Virtual Machine Manager (SCVMM) console when you configure the connection, as depicted in the illustration below.</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2017/03/a2.jpg"><img width="300" height="223" class="alignnone size-medium wp-image-3835" alt="a" src="https://msdnshared.blob.core.windows.net/media/2017/03/a2-300x223.jpg" /></a></p> <p>&nbsp;</p> <h2>Finding the BGP router IP address of the SDN gateway</h2> <h3>BGP Router IP for tenant connections</h3> <p>If you are using Border Gateway Protocol (BGP) with your tenant IPsec, GRE or L3 connections for dynamically learning remote routes, you need to know the BGP router IP address so that you can configure that address as the peer address on the remote router. When you configure the VPN connections through SCVMM, SCVMM automatically assigns an IP Address from the gateway routing subnet to the tenant compartment of the gateway VM. SCVMM uses this IP address as the BGP router IP address. Because this router is tenant-specific, the router address is different for each tenant.</p> <p>First, execute the following Windows Powershell commands on a Network Controller machine or a machine that is configured as a Network Controller client:</p> <p><em>$gateway = Get-NetworkControllerVirtualGateway -ConnectionUri &lt;REST uri of your deployment&gt;</em></p> <p><em>$gateway.Properties.NetworkConnections.Properties.DestinationAddress</em></p> <p>The results of this command can display multiple virtual gateways, depending on how many tenants have configured gateway connections. Also, each virtual gateway can have multiple connections (IPSec, GRE, L3). Because you already know the destination address of the connection, you can identify the correct connection based on the destination address. After you have the correct network connection, run the following command (on the corresponding virtual gateway) to get the BGP router IP address of the virtual gateway</p> <p><em>$gateway.Properties.BgpRouters.Properties.RouterIp</em></p> <p>The result of this command provides the IP address that you must configure on the remote router as the peer IP Address.</p> <h3>BGP router IP for GRE gateway</h3> <p>If you are using GRE connectivity in your SDN deployment, you must create a GRE VIP logical network and advertise the GRE VIPs from your SDN gateways to the physical network using internal BGP peering. You can get more details in the SDN planning document <a href="https://technet.microsoft.com/en-us/windows-server-docs/networking/sdn/plan/plan-a-software-defined-network-infrastructure">here</a>.</p> <p>You need to create a BGP peer on the Top of Rack router (ToR) that is used by your SDN infrastructure to receive routes for the GRE VIP logical network advertised by the SDN Gateways. BGP peering only needs to occur one way (from SDN Gateway to external BGP peer). To configure the BGP peer, you will need to provide the peer IP i.e, the BGP router IP of the SDN gateways.</p> <p>To get the BGP router IP of the SDN gateway, execute the following Powershell commands on a Network Controller machine or a machine that is configured as a Network Controller client:</p> <p><em>$gateway = Get-NetworkControllerGateway -ConnectionUri &lt;REST uri of your deployment&gt;</em></p> <p><em>$gateway.Properties.BgpConfig.RouterIp</em></p> <p>The result of this command provides the IP address that you must configure on the remote router as the peer IP Address.</p> <p>&nbsp;</p> <p>If you want to setup SDN through SCVMM, there is a bunch of detailed documentation on Technet <a href="https://technet.microsoft.com/en-us/system-center-docs/vmm/scenario/sdn-overview">here</a>. Before starting the deployment, please go through the SDN planning guidance <a href="https://technet.microsoft.com/en-us/windows-server-docs/networking/sdn/plan/plan-a-software-defined-network-infrastructure">here</a>.</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/03/23/how-to-find-the-sdn-gateway-local-address-for-bgp-peering-in-windows-server-2016/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Troubleshoot Configuring SDN RAS Gateway VPN Bandwidth Settings in Virtual Machine Manager</title> <link>https://blogs.technet.microsoft.com/networking/2017/03/06/troubleshoot-configuring-sdn-ras-gateway-vpn-bandwidth-settings-in-virtual-machine-manager/</link> <comments>https://blogs.technet.microsoft.com/networking/2017/03/06/troubleshoot-configuring-sdn-ras-gateway-vpn-bandwidth-settings-in-virtual-machine-manager/#respond</comments> <pubDate>Mon, 06 Mar 2017 17:38:31 +0000</pubDate> <dc:creator><![CDATA[AnirbanPaul]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[bandwidth]]></category> <category><![CDATA[Gateway]]></category> <category><![CDATA[RRAS]]></category> <category><![CDATA[SDN]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[Windows Server 2016]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3785</guid> <description><![CDATA[I wanted to share some of my experiences with debugging Windows Server 2016 Software Defined Networking (SDN) related customer issues. These issues are related to SDN RAS Gateways.If you’ve deployed Software Defined Networking (SDN) in Windows Server 2016 Datacenter by using System Center Virtual Machine Manager (SCVMM), you might have encountered problems configuring the RAS Gateway... <a aria-label="read more about Troubleshoot Configuring SDN RAS Gateway VPN Bandwidth Settings in Virtual Machine Manager" href="https://blogs.technet.microsoft.com/networking/2017/03/06/troubleshoot-configuring-sdn-ras-gateway-vpn-bandwidth-settings-in-virtual-machine-manager/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p><span>I wanted to share some of my experiences with debugging Windows Server 2016 Software Defined Networking (SDN) related customer issues. These issues are related to SDN RAS Gateways.If you’ve deployed Software Defined Networking (SDN) in Windows Server 2016 Datacenter by using System Center Virtual Machine Manager (SCVMM), you might have encountered problems configuring the RAS Gateway virtual private network (VPN) connection inbound and outbound bandwidth settings.</span></p> <p>Gateways are used in SDN to provide external connectivity to a virtual network. This can be connectivity to an on-premises network or to the physical network in the same datacenter. You can get more information about gateways in the topic <a href="https://technet.microsoft.com/en-us/windows-server-docs/networking/sdn/technologies/network-function-virtualization/ras-gateway-for-sdn">RAS Gateway for SDN</a>.</p> <p><strong>Issue #1</strong></p> <p>The customer was unable to change VPN connection inbound and outbound bandwidth settings by using the SCVMM user interface (UI) setting <strong>Maximum Incoming</strong> and <strong>Maximum Outgoing</strong>.</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-01.jpg"><img width="300" height="226" class="alignnone size-medium wp-image-5535" alt="scvmm-01" src="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-01-300x226.jpg" /></a></p> <p><span>When the customer tried to change these gateway bandwidth settings from the SCVMM UI, he received the error ID 26909, <strong>Network service ‘SA19N30NC’ doesn’t support this type of traffic metering, </strong>as depicted in the following screen shot.</span></p> <p><a href="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-02.jpg"><img width="300" height="226" class="alignnone size-medium wp-image-5545" alt="scvmm-02" src="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-02-300x226.jpg" /></a></p> <p><strong>Solution for Issue #1</strong></p> <p>SCVMM currently does not support changing bandwidth settings for a VPN connection. They will start supporting this shortly. By default, the inbound and outbound bandwidth is set as 500 Kbps.</p> <p>Meanwhile, if you want to change bandwidth settings, you can use the Network Controller Windows PowerShell command <a href="https://technet.microsoft.com/itpro/powershell/windows/network-controller/new-networkcontrollervirtualgatewaynetworkconnection">New-NetworkControllerVirtualGatewayNetworkConnection</a> with the parameters <strong>OutboundKiloBitsPerSecond</strong> and <strong>InboundKiloBitsPerSecond</strong>.</p> <p><em>NOTE: If you make any other changes to the VPN connection through SCVMM after changing the bandwidth settings, the bandwidth settings will be reset to the default (500 Kbps). So, you will need to run the Network Controller Powershell again to update the bandwidth settings.</em></p> <p><strong>Issue #2</strong></p> <p><span>Even after changing the VPN network connection bandwidth settings to 200 Mbps by using Network Controller Windows PowerShell commands, the customer observed a bandwidth cap of about 150 Mbps for the connection.</span></p> <p><strong>Solution for Issue #2</strong></p> <p>The customer had set the gateway capacity as 1000 Mbps (this is the default value in the SCVMM UI). <span>The <strong>Gateway capacity (Mbps)</strong> parameter denotes the normal TCP bandwidth which is expected out of the gateway VM. Customer should fill this accordingly based on his underlying network speed.</span></p> <p><a href="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-03.jpg"><img width="300" height="226" class="alignnone size-medium wp-image-5555" alt="scvmm-03" src="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-03-300x226.jpg" /></a></p> <p><span>Maximum IPsec tunnel bandwidth is limited to (3/20)* Gateway Capacity on a particular gateway. So, if the gateway capacity is set to 1000 Mbps, the equivalent IPsec tunnel capacity would be 150 Mbps.</span></p> <p><span>The equivalent ratios for GRE and L3 tunnels are 1/5 and 1/2, respectively.</span></p> <p><span>NOTE: You must be wondering why the customer was allowed to add a connection with 200 Mbps bandwidth if the gateway did not have available capacity. Actually, the configuration change never succeeded. This configuration change is an asynchronous operation. After changing the settings, if the customer had executed <strong>Get-NetworkControllerVirtualGatewayNetworkConnection</strong> and checked the <strong>ConfigurationState</strong> of the resource, the “Status” would have been “Failure” with “DetailedInfo” giving more details about the error. </span></p> <p>If you want to setup SDN through SCVMM, see the topic <a href="https://technet.microsoft.com/en-us/system-center-docs/vmm/scenario/sdn-overview">Set up a Software Defined Network (SDN) infrastructure in the VMM fabric</a>. Before starting the setup, you can review the SDN planning guidance in the topic <a href="https://technet.microsoft.com/en-us/windows-server-docs/networking/sdn/plan/plan-a-software-defined-network-infrastructure">Plan a Software Defined Network Infrastructure</a>.</p> <p>Anirban Paul, Senior Program Manager</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/03/06/troubleshoot-configuring-sdn-ras-gateway-vpn-bandwidth-settings-in-virtual-machine-manager/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Dynamic DNS registration process can cause queue build up and failures</title> <link>https://blogs.technet.microsoft.com/networking/2016/11/25/dynamic-dns-registration-process-can-cause-queue-build-up-and-failures/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/11/25/dynamic-dns-registration-process-can-cause-queue-build-up-and-failures/#respond</comments> <pubDate>Fri, 25 Nov 2016 11:55:26 +0000</pubDate> <dc:creator><![CDATA[Kaushik Ainapure [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3745</guid> <description><![CDATA[Hey Folks! Ajay Sarkaria here with new information on the changes in dynamic DNS registrations. In the past, we have had many customers who call Microsoft support with scenarios where dynamic DNS registration from a Microsoft DHCP server either fail or is delayed. This causes printers or other critical devices to not get registered or... <a aria-label="read more about Dynamic DNS registration process can cause queue build up and failures" href="https://blogs.technet.microsoft.com/networking/2016/11/25/dynamic-dns-registration-process-can-cause-queue-build-up-and-failures/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p>Hey Folks! Ajay Sarkaria here with new information on the changes in dynamic DNS registrations. In the past, we have had many customers who call Microsoft support with scenarios where dynamic DNS registration from a Microsoft DHCP server either fail or is delayed. This causes printers or other critical devices to not get registered or get registered with delays.</p> <p>This issue has been difficult to diagnose as the current logs did not provide adequate visibility into the reasons for the failures.</p> <h5>Scenario:</h5> <p>Dynamic DNS updates are attempts to update the PTR record, which is often done in conjunction with HOST A record update. In order to send a PTR update an SOA query is made first for the reverse record for the host to see who is authoritative to accept the update. In case the DNS Server does not have a reverse lookup zone, an error sent back to the DHCP server is interpreted as a general update failure, and this would cause re-queuing of the update request at the DHCP server, eventually causing a queue build-up.</p> <h6>Symptoms:</h6> <ul> <li>Devices after a renewal from Microsoft DHCP Server, fail to update their records in DNS</li> </ul> <p><b><u>For context, the following is how DHCP server-DNS client interaction works:</u></b></p> <p>Whenever a device obtains a new IP address lease from the DHCP server, DHCP server sends a dynamic DNS update request to the DNS server. The DHCP Server does so by calling a DNS client API which puts the request in the dynamic DNS update processing queue of the DNS client. At start of the DHCP server service, DHCP server sets the length of the dynamic DNS update queue in the DNS client. By default, it is set to 2048. It can be overridden by a DHCP server registry key. DHCP server registers a callback function with the DNS client to be called once the dynamic DNS update is completed either successfully or otherwise. DNS clients make 3 attempts to register each DNS record in the queue with a time interval of 5 minutes between retries. When the number of attempts are unsuccessful or the registration is successful, DNS client de-queues the request and calls DHCP server via a callback function indicating success or failure. If the callback function indicates a failure of the registration, DHCP server maintains in it’s lease database that this DNS update status for the lease is “Pending”.</p> <p>If the dynamic DNS registration is successful, it’s marked as “Complete”. A background process (scavenger) in DHCP server wakes up every hour, goes through the lease database and calls the DNS client API to register leases where the DNS update status is “Pending”. These attempts also go to the same DNS client queue mentioned above. If the queue becomes full, scavenger does not call the DNS registration API and moves to process the next unregistered IP address in the lease database.</p> <p>What has been observed is there is often a missing configuration which causes failure of dynamic DNS registration. The more common one being reverse lookup zone not being present. Given the above implementation, in a situation where the reverse lookup zone is not present, the queue inside the DNS client builds up and causes long delays in the registration of other DHCP clients which should have gone through.</p> <p><b><u>To alleviate this problem, the below was done: </u></b></p> <h4><b>On Windows Server 2016: </b></h4> <ol> <li>Currently the DHCP server logs do not give information to an administrator on why the DNS registrations are failing. New events are added in DHCP server on Windows Server 2016 which will help to easily identify that the DNS registration is failing because of a missing reverse lookup zone. You can then resolve the issue by adding that zone on the DNS server. <p><b><strong>New Events in Windows Server 2016:</strong></b></li> </ol> <table width="611" border="1" cellspacing="0" cellpadding="0"> <tbody> <tr> <td width="112" valign="top"><b>Event Category</b></td> <td width="512" valign="top"><b>Event Text</b></td> </tr> <tr> <td width="112" valign="top">DHCPv4.ForwardRecordDNSFailure</td> <td width="512" valign="top">Forward record registration for IPv4 address %1 and FQDN %2 failed with error %3. This is likely to be because the forward lookup zone for this record does not exist on the DNS server.</td> </tr> <tr> <td width="102" valign="top">DHCPv4.ForwardRecordDNSTimeout</td> <td width="512" valign="top">Forward record registration for IPv4 address %1 and FQDN %2 failed with error %3.</td> </tr> <tr> <td width="102" valign="top">DHCPv4.PTRRecordDNSFailure</td> <td width="512" valign="top">PTR record registration for IPv4 address %1 and FQDN %2 failed with error %3. This is likely to be because the reverse lookup zone for this record does not exist on the DNS server.</td> </tr> <tr> <td width="102" valign="top">DHCPv4.PTRRecordDNSTimeout</td> <td width="512" valign="top">PTR record registration for IPv4 address %1 and FQDN %2 failed with error %3</td> </tr> <tr> <td width="102" valign="top">DHCPv6.ForwardRecordDNSFailure</td> <td width="512" valign="top">Forward record registration for IPv6 address %1 and FQDN %2 failed with error %3. This is likely to be because the forward lookup zone for this record does not exist on the DNS server.</td> </tr> <tr> <td width="112" valign="top">DHCPv6.ForwardRecordDNSTimeout</td> <td width="512" valign="top">Forward record registration for IPv6 address %1 and FQDN %2 failed with error %3.</td> </tr> <tr> <td width="102" valign="top">DHCPv6.PTRRecordDNSFailure</td> <td width="512" valign="top">PTR record registration for IPv6 address %1 and FQDN %2 failed with error %3. This is likely to be because the reverse lookup zone for this record does not exist on the DNS server.</td> </tr> <tr> <td width="102" valign="top">DHCPv6.PTRRecordDNSTimeout</td> <td width="512" valign="top">PTR record registration for IPv6 address %1 and FQDN %2 failed with error %3.</td> </tr> <tr> <td width="102" valign="top">DHCPv4.ForwardRecordDNSError</td> <td width="512" valign="top">Forward record registration for IPv4 address %1 and FQDN %2 failed with error %3 (%4).</td> </tr> <tr> <td width="102" valign="top">DHCPv4.PTRRecordDNSError</td> <td width="512" valign="top">PTR record registration for IPv4 address %1 and FQDN %2 failed with error %3 (%4).</td> </tr> <tr> <td width="102" valign="top">DHCPv6.ForwardRecordDNSError</td> <td width="512" valign="top">Forward record registration for IPv6 address %1 and FQDN %2 failed with error %3 (%4).</td> </tr> <tr> <td width="102" valign="top">DHCPv6.PTRRecordDNSError</td> <td width="512" valign="top">PTR record registration for IPv6 address %1 and FQDN %2 failed with error %3 (%4).</td> </tr> </tbody> </table> <p>2. The second change is related to retries in the DNS client. The current implementation made 3 attempts at failed registrations with a time interval of 5 minutes between them. In the scenario of a missing DNS zone, there will be several registrations which will fail and will be present in the DNS client queue for as long as 10 minutes. This causes the queue length to be hit and other valid registrations do not get done or get delayed a lot. In other words, the impact of a missing configuration like reverse lookup zone not being present becomes quite severe.</p> <p>So, a change was made in DNS client to not make any retries for failed registrations. Failed registrations will anyway be retried by the scavenger in the DHCP server as mentioned above. This will ensure that in cases when a zone is not present, the failed registration does not stay in the queue for a long time and the queue build will not be seen. This feature is enabled by default in Windows Server 2016.</p> <h4><b>On Windows Server 2012 R2: </b></h4> <ul> <li>The change in Windows Server 2012 R2 is related to only the retries in the DNS client as mentioned in # 2 above for Windows Server 2016 &amp; no additional events have been added.</li> </ul> <p><b><u>How to get this change on Windows Server 2012 R2?</u></b></p> <p>The change <b>(not enabled by default)</b> is part of the following Monthly Quality Rollup for Windows Server 2012 R2:</p> <blockquote> <h6><a target="_blank" href="https://support.microsoft.com/en-us/kb/3197875">November 2016 Preview of Monthly Quality Rollup for Windows 8.1 and Windows Server 2012 R2</a></h6> </blockquote> <p><strong>Important:</strong> The behavior does not change by simply installing the Monthly Quality Rollup for Windows Server 2012 R2 (<a href="https://support.microsoft.com/en-us/kb/3197875">KB3197875</a>). It is controlled by a registry setting which needs to be implemented:</p> <p><b>Disclaimer</b>: It is always a good idea to take a backup of the registry key before making any changes so please do that!</p> <ol> <li>Create a new key called <i>&#8220;DnsRegistrationMaxRetries&#8221;</i> of type DWORD under<br /> HKLM\System\CurrentControlSet\Services\DhcpServer\Parameters</li> <li>Set the value of <i>&#8220;DnsRegistrationMaxRetries&#8221;</i> to <b>0</b></li> <li>Reboot the DHCP Server</li> </ol> <p><b>Note</b>: If you already have <a href="https://support.microsoft.com/en-us/kb/3197875">KB3197875</a> installed, the <i>“DnsRegistrationMaxRetries”</i> may exist with value <b>3</b>. You need to change the value to <b>0</b> and reboot the DHCP Server.</p> <p>Until next time!</p> <p>Ajay Sarkaria<br /> Microsoft</p> <p>&nbsp;</p> <p><b></b></p> <p>&nbsp;</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/11/25/dynamic-dns-registration-process-can-cause-queue-build-up-and-failures/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Network Virtualization in the Windows Server 2016 Software Defined Networking (SDN) Stack</title> <link>https://blogs.technet.microsoft.com/networking/2016/10/26/network-virtualization-with-ws2016-sdn/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/10/26/network-virtualization-with-ws2016-sdn/#comments</comments> <pubDate>Wed, 26 Oct 2016 20:59:08 +0000</pubDate> <dc:creator><![CDATA[Windows Networking Team [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[HNV]]></category> <category><![CDATA[Networking]]></category> <category><![CDATA[SDN]]></category> <category><![CDATA[VXLAN]]></category> <category><![CDATA[Windows Server]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3685</guid> <description><![CDATA[By Jason Messer, Senior Program Manager Using VXLAN for Encapsulation and OVSDB for Policy Distribution Windows Server 2016 is the perfect platform for building your Software-Defined Data Center (SDDC) with new layers of security and Azure-inspired innovation for hosting business applications and infrastructure. A critical piece of this SDDC is the new Software Defined Network... <a aria-label="read more about Network Virtualization in the Windows Server 2016 Software Defined Networking (SDN) Stack" href="https://blogs.technet.microsoft.com/networking/2016/10/26/network-virtualization-with-ws2016-sdn/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p><em>By Jason Messer, Senior Program Manager</em></p> <p><em>Using VXLAN for Encapsulation and OVSDB for Policy Distribution</em></p> <p>Windows Server 2016 is the perfect platform for building your Software-Defined Data Center (SDDC) with new layers of security and Azure-inspired innovation for hosting business applications and infrastructure. A critical piece of this SDDC is the new Software Defined Network (SDN) Stack which provides agility, dynamic security, and hybrid flexibility by enforcing network policy in the Hyper-V Virtual Switch using the Azure Virtual Filtering Platform (VFP) Switch Extension. Instead of programming network configurations into a physical switch using CLI, NetConf, or OpenFlow, the network policy is instead delivered from the new Microsoft Network Controller to the Hyper-V Hosts using the OVSDB protocol and programmed into the VFP extension of the vSwitch by a Host Agent which enforces the policy. By creating overlay virtual networks (VXLAN Tunnels / logical switches) and endpoints which terminate in the vSwitch, each Hyper-V host becomes a software VXLAN Tunnel End Point (VTEP).</p> <p><em>Note: This will be a technical post focusing on networking protocols and some implementation details</em></p> <h1>Virtual Networking</h1> <p>Overlays, VXLAN, virtual networking, HNV, encapsulation, NVGRE, logical switch… why should you care about all these esoteric networking terms? Maybe you have heard hard-core networking types mention these in passing or have customers asking how Microsoft’s network virtualization solution compares with other solutions. Why should you care? <em><u>Because just as compute and storage have been virtualized, traditional networking devices and services are also being virtualized for greater flexibility.</u></em></p> <p>Server hardware is now virtualized through software to mimic CPUs, memory, and disks to create virtual machines. Network hardware is also being virtualized to mimic switches, routers, firewalls, gateways, and load balancers to create <strong>virtual networks</strong>. Not only do virtual networks provide isolation between workloads, tenants, and business units but they also allow IT and network administrators to configure networks and define policy with agility while realizing increased flexibility in where VMs are deployed and workloads run.</p> <p>Virtual networks still require physical hardware and IP networks to connect servers and VMs together. However, the packets transmitted between VMs across these physical links are <strong>encapsulated</strong> within physical network IP packets to create an <strong>overlay</strong> network – Reference Figure 1. This means that the original packet from the VM with its MAC and IP addresses, TCP/UDP ports, and data remains unchanged and is simply placed inside of an IP packet on the physical network. The physical network underneath is then known as the underlay or transport network – traditionally Microsoft has called this the HNV Provider (or PA) network.</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/10/VXLANEncap.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/10/VXLANEncap-300x169.jpg" width="300" height="169" class="alignnone wp-image-3695 size-medium" /></a></p> <p><em><u>Figure 1 – VXLAN Encapsulation</u></em></p> <p>The idea of network virtualization to guarantee isolation has been around for some time in the form of VLANs. VLANs allow network traffic to be “tagged” with an identifier to create logical network segments and segregate network traffic into broadcast and isolation domains. However, VLANs are largely <em>static configurations</em> programmed on individual switch ports and network adapters. Anytime a server or VM moves, the VLAN configuration must be updated (sometimes in multiple places) and the IP addresses of that workload or VM may need to be changed as well. Moreover, since VLANs use a 12-bit field for the network identifier, there is a limit of 4096 logical network segments which can be created.</p> <h1>Hyper-V Network Virtualization (HNV)</h1> <p>The network virtualization solution in Windows Server 2012 and 2012R2 – Hyper-V Network Virtualization (<strong>HNV</strong>) – used an encapsulation format known as <strong>NVGRE</strong> (<a href="https://datatracker.ietf.org/doc/rfc7637/">RFC 7637</a>) to create overlay networks based on network policy managed through SCVMM and programmed through WMI / PowerShell. Another popular industry protocol for encapsulation is <strong>VXLAN </strong>(<a href="https://tools.ietf.org/html/rfc7348">RFC 7348</a>) including guidance on how to distribute or exchange <strong>VXLAN Tunnel Endpoint (VTEP)</strong> information between virtual and physical devices – e.g. Hardware VTEPs.</p> <p><em>Note: The HNV solution in Windows Server 2012 and 2012R2 which used NVGRE for encapsulation and WMI/PowerShell for management is still available in Windows Server 2016. We strongly recommend customers move to Windows Server 2016 and the new SDN stack, as the bulk of development and innovation will occur on this stack as opposed to HNVv1.</em></p> <p>In talking with customers, we observed some confusion around which encapsulation protocol to use (VXLAN or NVGRE), which was taking focus away from the higher-level value of network virtualization. Consequently, in Windows Server 2016 (WS2016), we support both NVGRE and VXLAN encapsulation protocols, with the default being VXLAN. We also built the Microsoft Network Controller as a programmable surface to create and manage these virtual networks and apply fine-grained policies for security, load balancing, and Quality of Service (QoS). A distinct management-plane – either PowerShell scripts, System Center Virtual Machine Manager (SCVMM), or the Microsoft Azure Stack (MAS) components – programs network policy through the RESTful API exposed by the Microsoft Network Controller. The Network Controller then distributes this policy to each of the Hyper-V hosts using the OVSDB Protocol and a set of schemas to represent virtual networks, ACLs, user-defined routing, and other policy.</p> <p>Like VLANs, both NVGRE and VXLAN provide isolation by including an identifier (e.g. VXLAN Network Identifier – VNI) to identify the logical network segment (virtual subnet). In WS2016, multiple VNIs (or virtual subnets) can be combined within a <strong>Routing Domain</strong> so that isolation between tenant virtual networks is maintained thereby allowing for overlapping IP address spaces.  A network compartment is created on the Hyper-V host for each routing domain with a Distributed Router used to route traffic between virtual subnets for a given tenant. Admins can also create User-Defined Routes to chain virtual appliances into the traffic path for increased security and functionality. Unlike physical networks with VLANs where policy is closely tied to location and the physical port to which a server (hosting a VM) is attached, a network endpoint (VM) is free to move across the datacenter while ensuring that all policy moves along with it.</p> <p><em></em>As network equipment manufacturers build support for VXLAN into their NIC cards, switches, and routers, they can support:</p> <ul> <li>Encapsulation Task Offloads to offload operations from the OS and Host CPU onto the NIC Card</li> <li>ECMP Spreading using the UDP source port as a hash to distribute connections</li> </ul> <p>Microsoft has worked with the major NIC vendors to ensure support exists for both NVGRE and VXLAN Task Offloads in Windows Server 2016 NIC drivers. These offloads take the processing burden off the Host CPU and instead perform functions such as LSO and Inner Checksums on the physical NIC card itself. Moreover, Microsoft conforms to the standard VXLAN UDP source port hash over the inner packet to ensure ECMP spreading for different connections will just work from ECMP-enabled routers.</p> <h1>VXLAN Implementation in Windows Server 2016</h1> <p>TCP/IP stacks rely on the Address Resolution Protocol (ARP) and port learning performed by traditional layer-2 switches to determine the MAC address of the remote hosts and the ports on a switch to which they are connected. Overlay Virtual Networking encapsulates the VM traffic’s packet headers and data (inner packet) inside of a Layer-3 IP (outer) packet transmitted on the underlay (physical) network. Therefore, before a VM attached to a virtual network can send a unicast packet destined for another VM in the same virtual subnet, it must first learn or be told the remote VM MAC address as well as the VTEP IP address of the host on which the VM is running. This allows the VM to place the correct Destination MAC address in the inner packet’s Ethernet header and for the host to build the encapsulated packet with the correct Destination IP address to deliver the packet to the remote host.</p> <p>The VXLAN RFC talks about different approaches for distributing the VTEP IP to VM MAC mapping information:</p> <ol> <li>Learning-based control plane</li> <li>Central Authority-/directory-based lookup</li> <li>Distribution of this mapping information to the VTEPs by the central authority</li> </ol> <p>In a learning-based control-plane, encapsulated packets having an unknown destination (VTEP IP) are sent out via broadcast or to an IP multicast group. This requires a mapping between a multicast group and each virtual subnet (identified by a VXLAN Network Identifier (VNI)) such that any VTEPs which host VMs attached to this VNI register for the group through IGMP. The VM MAC addresses and remote host’s IP address (VTEP IP) are then discovered via source-address learning. A clear disadvantage of this approach is that it places a lot of unnecessary traffic on the wire which most network administrators try to avoid.</p> <p>Based on our learnings in Azure, Microsoft chose the distribution by a central authority (i.e. Microsoft Network Controller) approach to send out the VM MAC : VTEP IP mapping information to avoid the unnecessary broadcast/multicast network traffic. The Microsoft Network Controller (OVSDB Client) communicates with the Hyper-V Hosts (VTEPs) using the OVSDB protocol with policy represented in schemas persisted to a Host Agent’s database (OVSDB Server). A local ARP responder on the host is then able to catch and respond to all ARP requests from the VMs to provide the destination MAC address of the remote VM. The Host Agent database also contains the VTEP IP address of all hosts attached to the virtual subnet. The Host Agent programs mapping rules into the VFP extension of the Hyper-V Virtual Switch to correctly encapsulate and send the VM packet based on the destination VM.</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/10/NC-HA-Communication.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/10/NC-HA-Communication-300x169.jpg" alt="NC-HA Communication" width="300" height="169" class="alignnone size-medium wp-image-3705" /></a></p> <p><em><u>Figure 2 – Network Controller &#8211; Host Agent Communication</u></em></p> <h1>Looking Ahead</h1> <p>At present, Microsoft’s implementation of VXLAN does not support interoperability with third party hardware VTEPs due to a difference in OVSDDB schemas. We created a custom OVSDB schema to convey additional policy information such as ACLs and service chaining which was not available in the initial hardware_VTEP schema. However, support for the core protocols  (VXLAN, OVSDB) is in place in the platform for us to bring in support for hardware VTEPs in the future. Our current thinking on implementation is that we will support the hardware_VTEP schema in our Network Controller and distribute mapping information to the hardware VTEPs. We do not think that a learning-based control plane is the right solution due to the increased amount of multicast/broadcast required on the network – network admins are already trying to limit this L2 traffic which by some accounts consumes 50% of network capacity.</p> <p>If this is something of interest, please do reply in the comments field below and let us know. We’d love to speak with you.</p> <h1>SDN Network Virtualization Key Features</h1> <ul> <li>Create thousands of logical network segments</li> <li>User-Defined Routing (UDR) for Virtual Appliances</li> <li>Multi-tenancy support through individual routing domains</li> <li>VXLAN and NVGRE encapsulation</li> <li>Distributed Router on each Hyper-V host</li> <li>Integration with Software Load Balancer (SLB), Gateways, QoS, and Distributed Firewall</li> <li>Network virtualization policy programmed through the Microsoft Network Controller using OVSDB</li> </ul> <p>&nbsp;</p> <h1>RESOURCES</h1> <h3>Documentation</h3> <ul> <li><a href="https://technet.microsoft.com/en-us/library/mt403307.aspx">Planning and Deployment</a></li> <li><a href="https://technet.microsoft.com/en-us/library/dn931986.aspx">Hyper-V Network Virtualization</a></li> <li><span> </span><a href="https://technet.microsoft.com/en-us/library/mt703757.aspx">Manage Tenant Virtual Networks</a></li> </ul> <h3>Deployment Scripts</h3> <ul> <li><span> </span><a href="https://github.com/Microsoft/SDN">Microsoft/SDN GitHub repo</a></li> </ul> <h3>Blogs</h3> <ul> <li><a href="https://blogs.technet.microsoft.com/windowsserver/2016/04/20/ten-reasons-youll-love-windows-server-2016-7-software-defined-networking/">Ten reasons you&#8217;ll love Windows Server 2016 #7: Software-defined networking</a></li> <li><a href="https://blogs.technet.microsoft.com/windowsserver/2015/11/04/4-datacenter-challenges-and-how-windows-server-2016-software-defined-networking-can-help/">4 datacenter challenges and how SDN can help</a></li> </ul> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/10/26/network-virtualization-with-ws2016-sdn/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>An Update on Windows TCP AutoTuningLevel</title> <link>https://blogs.technet.microsoft.com/networking/2016/08/11/an-update-on-windows-tcp-autotuninglevel/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/08/11/an-update-on-windows-tcp-autotuninglevel/#comments</comments> <pubDate>Thu, 11 Aug 2016 22:31:49 +0000</pubDate> <dc:creator><![CDATA[Windows Networking Team [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3645</guid> <description><![CDATA[Daniel Havey, Praveen Balasubramanian Like all modern operating systems Windows has receive window auto-tuning to dynamically adjust the receive buffer size to the throughput and latency of the link. Disabling this feature will definitely limit your Internet speeds. Auto-tuning is consistent throughout all variants of TCP and present in all modern operating systems.   In... <a aria-label="read more about An Update on Windows TCP AutoTuningLevel" href="https://blogs.technet.microsoft.com/networking/2016/08/11/an-update-on-windows-tcp-autotuninglevel/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p><span style="color: #5a5a5a;font-family: Calibri">Daniel Havey, Praveen Balasubramanian</span></p> <p>Like all modern operating systems Windows has receive window <a href="https://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx">auto-tuning</a> to dynamically adjust the receive buffer size to the throughput and latency of the link. Disabling this feature will <strong>definitely limit your Internet speeds. </strong>Auto-tuning is consistent throughout all variants of TCP and present in all modern operating systems. <span> </span> In the modern Internet the range of latencies and throughput speeds that must be accommodated is simply too large to manage statically and must be adjusted dynamically. If you have changed your AutoTuningLevel to disabled, please reset it to <span> </span>normal in order to restore your Internet speeds using the following commands in an elevated command prompt:</p> <blockquote> <pre>PS C:\WINDOWS\system32&gt; netsh int tcp set global autotuninglevel=normal Ok. PS C:\WINDOWS\system32&gt; netsh interface tcp show global Querying active state... TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State     : enabled Chimney Offload State                : disabled NetDMA State                         : disabled Direct Cache Access (DCA)            : disabled <strong>Receive Window Auto-Tuning Level      : normal</strong> Add-On Congestion Control Provider   : none ECN Capability                       : disabled RFC 1323 Timestamps                  : disabled Initial RTO                          : 3000 Receive Segment Coalescing State     : disabled Non Sack Rtt Resiliency              : disabled Max SYN Retransmissions              : 2 TCP Fast Open                        : enabled</pre> </blockquote> <p>Some of the confusion may have originated from a misinterpretation of a blog post which suggests disabling heuristics with the following command:</p> <blockquote> <pre>netsh interface tcp set heuristics disabled</pre> </blockquote> <p>Heuristics is a feature that can interfere with auto-tuning and disabling it can improve Internet speeds and in fact heuristics have already been disabled in Windows 8.1 and greater. Auto-Tuning on the other hand should NEVER be disabled.</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/08/11/an-update-on-windows-tcp-autotuninglevel/feed/</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>How to prevent accidental DNS Zone deletions in Windows Server</title> <link>https://blogs.technet.microsoft.com/networking/2016/08/11/how-to-prevent-accidental-dns-zone-deletions-in-windows-server/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/08/11/how-to-prevent-accidental-dns-zone-deletions-in-windows-server/#respond</comments> <pubDate>Thu, 11 Aug 2016 13:29:34 +0000</pubDate> <dc:creator><![CDATA[Kaushik Ainapure [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[Deletion]]></category> <category><![CDATA[DNS Zone]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3605</guid> <description><![CDATA[My name is Ajay Sarkaria and I am a Supportability Program Manager at Microsoft. We have been seeing support volumes where administrators while performing daily tasks may accidentally delete a DNS Zone which is being used in production. This post comes with inputs from our friends in Microsoft PFE team Brent Whitlow; Bryan Zink; Michael... <a aria-label="read more about How to prevent accidental DNS Zone deletions in Windows Server" href="https://blogs.technet.microsoft.com/networking/2016/08/11/how-to-prevent-accidental-dns-zone-deletions-in-windows-server/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p>My name is Ajay Sarkaria and I am a Supportability Program Manager at Microsoft. We have been seeing support volumes where administrators while performing daily tasks may accidentally delete a DNS Zone which is being used in production.</p> <p>This post comes with inputs from our friends in Microsoft PFE team <b>Brent Whitlow; <strong>Bryan Zink; Michael Hildebrand &amp; Eric Jansen</strong></b></p> <p><b>Note</b>: After you follow the below steps, you will not be able to delete or change the scope of replication for the DNS Zone unless you first unprotect the zone from accidental deletion.</p> <p>Example screenshot if trying to delete from Active Directory Users and Computers:</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion1.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion1-300x104.jpg" alt="DNS_Zone_Deletion1" width="476" height="165" class="alignnone wp-image-3637" /></a></p> <p><i>“You do not have sufficient permissions to delete DNZ_Zone_Name, or this object is protected from accidental deletion”</i></p> <p>OR</p> <p>Example screenshot if trying to delete from the DNS Manager:</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion2.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion2.jpg" alt="DNS_Zone_Deletion2" width="256" height="163" class="alignnone size-full wp-image-3606" /></a></p> <p><i>The zone cannot be deleted.<br /> </i><i>Access was denied</i></p> <p>If you try to change the scope of replication with the protection enabled, you will see a message similar to the below:</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion3.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion3-300x254.jpg" alt="DNS_Zone_Deletion3" width="401" height="340" class="alignnone wp-image-3615" /></a></p> <p><i>The replication scope could not be set. For more information, see &#8220;DNS zone replication in Active Directory&#8221; in Help and Support. The error was: </i></p> <p><i>Access was denied.</i></p> <p>&nbsp;</p> <p>Now, am going to highlight steps which an administrator can perform to prevent such accidental deletions in the first place. If you remember, Active Directory has a great feature which prevents accidental deletions of Organizational Units by checking a flag. We are going to discuss something similar to prevent accidental DNS Zone deletions.</p> <p><b>Important:</b> As with any changes, you should <strong><u>always</u></strong> exercise caution and test things out in a lab BEFORE implementing any changes to your production environment.</p> <p>Ensuring you have a LAB setup to test the changes first, let’s configure the DNS Zones from accidental deletions. There are a couple of way to prevent accidental DNS zone deletions</p> <p><b>DNS Zones stored in the Domain Partition:</b></p> <p>Doing it from the Active Directory Users &amp; Computers MMC:</p> <ol> <li>Check the flag of “<i>Protect object from accidental deletion”</i> by browsing to Active Directory Users and Computers \ Domain Name \ System \ Microsoft DNS \ DNS Zone name</li> <li>Right click and select properties</li> <li>Select the Object Tab<a href="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion4.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion4-261x300.jpg" alt="DNS_Zone_Deletion4" width="353" height="406" class="alignnone wp-image-3625" /></a><b>Note</b>: The above flag will only be visible in Active Directory Users and Computers if you have stored the DNS Zone in the Domain Partition. You can check where your DNS Zone is stored in DNS Management UI. As an example, the below screenshot shows the replication scope set as “All domain controllers in this domain (for Windows 2000 compatibility)”<a href="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion5.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion5-300x91.jpg" alt="DNS_Zone_Deletion5" width="353" height="107" class="alignnone wp-image-3635" /></a></li> </ol> <p><b>PowerShell:</b></p> <ul> <li><b><b><b>Enumerate all DNS Zones not protected from deletion in the Domain partition: <p></b></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;CN=MicrosoftDNS,CN=System,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li><b><b><b>Set the protect from accidental deletion flag: <p></b></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;CN=MicrosoftDNS,CN=System,DC=domain,DC=lab &#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true</li> <li><strong><b>DNS Zones stored in Domain wide application partitions</b></strong><b><b>:</b></b> <ul> <li><b><b><b>Enumerate all DNS Zones not protected from deletion in the domain application partition: <p></b></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=DomainDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li><b><b>Set the protect from accidental deletion flag: <p></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=DomainDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true</li> </ul> </li> <li><strong><b>DNS Zones stored in Forest wide application partitions</b></strong><b><b>:</b></b> <ul> <li><b><b>Enumerate all DNS Zones not protected from deletion in the Forest Wide application partition: <p></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=ForestDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li><strong><strong>Set the protect from accidental deletion flag: <p></strong></strong>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=ForestDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true</li> </ul> </li> <li><strong><strong>Check the protect from accidental deletion flag:</strong></strong> <ul> <li><b><b>Forest wide application partition: <p></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=ForestDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li><b><b>Domain wide application partition: <p></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=DomainDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li><b><b>Domain Partition: <p></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;CN=MicrosoftDNS,CN=System,DC=domain,DC=lab &#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview</li> </ul> </li> </ul> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/08/11/how-to-prevent-accidental-dns-zone-deletions-in-windows-server/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> </channel> </rss>