NPS network policy with multiple Client ip4 addesses
I have a wireless policy on my NPS server with the primary wireless controller added using a Client IPv4 address entry in the policy. I want to add the backup controller as well but it seems it is adding it as a and condition. I need it to be added as an or condition when the primary controller is unreachable. How can I add multiple Client ip4 addessess in a Network policy with an or condition? An and condition would require both to be reachable. thanks.
Zero Trust DNS is Here: Elevating Enterprise Security on Windows 11
When attackers target an enterprise today, they rarely begin with a blunt smash-through-the-front-door intrusion. They begin quietly by resolving a domain. In most cases, modern malware, phishing kits, and human-operated ransomware operators rely on DNS as the entry point to discover infrastructure, beacon command-and-control, and exfiltrate data. Thus, it is becoming even more important to secure DNS to help protect against increasingly frequent, complex, and expensive cyberattacks. Enterprises have invested heavily in Protective DNS services with cutting-edge threat intelligence to identify and block malicious domains in real time but if an endpoint device can simply bypass them, the entire Zero Trust posture is weakened. Today, Microsoft is closing that gap. Introducing Zero Trust DNS (ZTDNS) We are excited to announce that Zero Trust DNS (ZTDNS) is now generally available on Windows 11 Enterprise and Windows 11 Education editions. ZTDNS is a new enterprise security feature in Windows that helps ensure DNS policy configured on the enterprise DNS server is enforced on the device. This is an important advancement for organizations working to enable that outbound connectivity on managed Windows devices aligns with enterprise authorization and policy. ZTDNS provides device-level enforcement of an enterprise’s DNS policy, in-box on Windows 11 helping ensure devices only communicate with destinations the organization intends. It doesn’t require installing and managing additional agents or maintaining a “best effort” block list on each endpoint device. With ZTDNS, the enterprise DNS resolver becomes the policy source of truth and Windows becomes the enforcement point. For more information, check out our documentation. This can be particularly useful for organizations in highly regulated industries, or where compliance with NIST standards is of paramount importance. Without ZTDNS, the system DNS client could be pointed to a network-provided malicious DNS server, which can resolve unapproved domains and return incorrect resolutions to redirect the system to attacker’s endpoint. If the malicious DNS server uses encrypted DNS, IT administrators won’t be able to analyze the DNS traffic to prevent or mitigate potential attacks. Applications can use their own DNS client to completely bypass system policies. Also, system remains vulnerable to in-network attackers. ZTDNS protects against these attack vectors by mandating the use of Windows DNS client and only sending encrypted DNS queries to the trusted DNS servers. Since ZTDNS blocks all outbound connections and local name resolution by default, the system is protected against in-network threats. Why is ZTDNS needed? In enterprise scenarios, DNS is no longer just a lookup mechanism but a policy decision point. However, without device-level enforcement, attackers can hijack device DNS to: Redirect DNS queries from the device to a malicious or compromised DNS server Use their own encrypted DNS client and bypass system DNS client Bypass DNS completely with direct IP connections In such cases, organizations lose the ability to control which network destinations the endpoint is allowed to reach even if a Protective DNS service is used. ZTDNS addresses this by only allowing outbound connections to IP addresses that were resolved by the trusted DNS server for a query issued by the Windows DNS client. More importantly, it achieves this without terminating end-to-end encryption. How does ZTDNS work? ZTDNS integrates the Windows DNS client with the Windows Filtering Platform to help enforce domain-name-based network lockdown using encrypted DNS. ZTDNS is off by default and can be configured on a Windows 11 device with an enterprise-approved DNS over HTTPS (DoH) or DNS over TLS (DoT) server. When enabled, ZTDNS blocks all outbound IP-based connections by default and only allows outbound connections to IP addresses resolved by the trusted DNS server or those added to the manual exception list by the IT administrator. It mandates the use of encrypted DNS (DoH or DoT) and only trusts the DNS resolutions initiated by the Windows DNS client and answered by the trusted DNS server to create outbound allow exceptions. This helps provide a strong, enforceable control that aligns with Zero Trust principles: all destinations are untrusted by default unless specifically permitted. In a nutshell, when configured and enabled, ZTDNS will have the following effects on your Windows 11 device: Encrypted DNS enforcement (DoH or DoT) Default deny for outbound IPv4 and IPv6 traffic Dynamic allow listing of IP addresses returned by trusted DNS servers Static allow listing of IP addresses approved by the IT administrator via manual exceptions Centralized logging of permitted and blocked connections Deploying ZTDNS ZTDNS is available in the latest builds of Windows 11 Enterprise and Windows 11 Education. To deploy ZTDNS, enterprises can configure and enable it via: netsh commands JSON configuration We are also actively developing a Microsoft Intune experience for ZTDNS and we will share more information when the details are available. For detailed deployment guidance, check out our official documentation. Join Me at Microsoft Ignite 2025 For customers attending Microsoft Ignite 2025, please join us at session BRK258: Inside Windows Security, from client to cloud to learn more about ZTDNS. Alternatively, you can also visit the Windows Resiliency Initiative & Windows Security booth to discuss ZTDNS in depth. Securing the Present, Innovating for the Future Security is a shared responsibility. Through collaboration across hardware and software ecosystems, we can build more resilient systems secure by design and by default, from Windows to the cloud, enabling trust at every layer of the digital experience. The updated Windows Security book is available to help you understand how to stay secure with Windows. Learn more about Windows 11 and Copilot+ PCs. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
Allow VMs attached to internal switch on hyper-V win2k19 access Internet
Hi, I have 4 VMs attached to an internal switch with IPs 10.10.0.*, assigned 10.10.0.1 to the switch. One of the NICs on the host has the 192.168.1.70 which I shared its connection with the internal switch but I am not able to browse internet from the VMs. What can be missing? ThanksAllow Hyper-V VM attached to Internal Switch access internet and host folders
I have Created an internal switch and attached it to 4 VMs (for a lab setup) on a win2k19 hyper-V host. The hyper-V is in the my local home subnet 192.168.0.1. The 4 VMs are configured with following IPs and gateway. VM1 10.10.0.10 -DefaultGateway 10.10.0.1 VM2 10.10.0.11 -DefaultGateway 10.10.0.1 VM3 10.10.0.12 -DefaultGateway 10.10.0.1 VM4 10.10.0.13 -DefaultGateway 10.10.0.1 In the lab document, it is not indicated how/where to assign the 10.10.0..1 IP? When I check the vEthernet (Private Network), It has "DHCP" for IP and got my local DNS IP. Checking its status, I see DHCP Enabled: Yes Autoconfiguration IPv4 Address: 169.254.32.39 IPv4 Subnet Mask: 255.255.0.0 IPv4 Default Gateway: Not sure where this 169.254.... IP comes from? I tried assigning the IP 10.10.0.1 to this but it fails. In fact I need to allow VMs to access some host folders as well as internet to download some Microsoft tools. Thanks for your help
Get-ClusterExcludedAdapter cmdlet
Following link https://learn.microsoft.com/en-us/powershell/module/failoverclusters/get-clusterexcludedadapter?view=windowsserver2025-ps when execute Get-ClusterExcludedAdapter cmdlet with error below Get-ClusterExcludedAdapter : The term 'Get-ClusterExcludedAdapter' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + Get-ClusterExcludedAdapter + ~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (Get-ClusterExcludedAdapter:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException same for cmdlet Add-ClusterExcludedAdapter (https://learn.microsoft.com/en-us/powershell/module/failoverclusters/add-clusterexcludedadapter?view=windowsserver2025-ps) Does anyone know why these commands are not available?Announcing Public Preview of Zero Trust DNS
In today's evolving cybersecurity landscape, traditional perimeter defenses are no longer sufficient . As organizations embrace the Zero Trust security model, ensuring that devices only communicate with trusted network destinations becomes paramount. We are excited to announce the public preview of Zero Trust DNS (ZTDNS), a new feature in Windows 11 Insider builds designed to enforce domain-name-based network access controls, enhancing your organization's security posture. ZTDNS empowers enterprise IT administrators to natively apply outbound domain-name-based network access controls on Windows 11 endpoints. This helps prevent access to untrusted destinations, reducing the risk of a slew of network attacks from malware communication to data exfiltration. What is Zero Trust DNS? ZTDNS integrates the Windows DNS client with trusted Protective DNS (PDNS) servers to control outbound IP traffic based on domain names. When ZTDNS is configured on a Windows 11 device to use PDNS servers that support DNS over HTTPS (DoH) or DNS over TLS (DoT), ZTDNS ensures that: The Windows DNS client forces the use of encrypted DNS and queries are only sent to the configured PDNS servers. Outbound traffic is permitted only to IP addresses resolved by these trusted PDNS servers or to IP ranges with a manual exception plumbed by the IT administrator. All other IPv4 and IPv6 outbound traffic is blocked by default, adhering to the "deny by default" principle of Zero Trust. A log of attempted outbound connections is maintained on the device. This approach reduces the need for deep packet inspection or reliance on insecure signals like plain-text DNS or Server Name Indication (SNI) when attempting to determine the domain name associated with outbound traffic. This makes ZTDNS an important tool in the Zero Trust toolbelt since DNS traffic and SNI are increasingly being encrypted. It also aligns with Zero Trust principles by assuming all destinations are untrusted by default, only allowing connections to destinations explicitly permitted through DNS resolutions provided by trusted PDNS servers. For more information, visit our previous blog post on design of ZTDNS. Threats Zero Trust DNS Helps Mitigate Implementing ZTDNS can bolster your defenses against various network-based threats, including: DNS Hijacking: By ensuring that only DNS resolutions from trusted PDNS servers are used, ZTDNS helps prevent attackers from redirecting traffic to malicious sites. Malicious Communications: Blocking outbound connections to IP addresses not resolved through trusted DNS queries helps disrupt phishing and even non-administrative malware stagers and beacons. Data Exfiltration: Restricting outbound traffic to approved domains reduces the risk of sensitive data being transmitted to unauthorized destinations without conducting analysis of domain name resolution patterns. Getting Started with Zero Trust DNS NOTE: Public Preview of ZTDNS has officially ended. The instructions below are no longer supported. We appreciate you taking the time to test out ZTDNS in Public Preview. Your valuable feedback has helped us improve ZTDNS. For further assistance, please reach out to ztdnspreview@microsoft.com. To enable ZTDNS in your environment: Get a supported Windows 11 build Enroll your device in the Windows Insider Program (Canary channel) and update to build 27766+. Unlock ZTDNS In an administrator command prompt, run: reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" /v Experiment4712 /d 0xbe8261eb /t REG_DWORD Reboot the device. Ensure all applications and services are configured to use the Windows DNS client Configure applications like Edge and Chrome to use the Windows DNS client instead of their custom client (disable BuiltInDnsClientEnabled policy). Add manual allow exceptions Teleconferencing applications like Teams use WebRTC which negotiates IP addresses for peers within a TLS tunnel and has no DNS visibility. These IP subnets are also publicly documented and need manual allow exceptions for the application to work with ZTDNS. Add manual allow exceptions for IP addresses that are necessary for your productivity applications/services but are not discovered through DNS. Here is a sample command, for manual allow exception, which needs to run in administrator command prompt: netsh ztdns add exception name=AppName description="Description of AppName" subnets=192.0.2.128/25,198.51.100.0/24,3fff::/48, 3fff:123::/38 Here is a link Microsoft 365 services that may need manual allow exceptions. Set your trusted Protective DNS server (needs to be DoH/ DoT capable) In an administrator command prompt, replace example data in following sample commands with information about your desired DNS server before running: netsh ztdns add server type=doh address=203.0.113.0 template=https://doh.resolver.example/dns-query netsh ztdns add server type=dot address=2001:db8::1 hostname=dot.resolver.example Enable ZTDNS ZTDNS can be enabled using Audit mode or Enforcement mode. Audit mode logs all expected ZTDNS behavior without the actual enforcement. Check out the next blog post for finding and comprehending ZTDNS logs. Enabling ZTDNS in audit mode is recommended before moving on to Enforcement mode. In an administrator command prompt, run: netsh ztdns set state enable=yes audit=yes Enforcement mode blocks untrusted traffic. In an administrator command prompt, run: netsh ztdns set state enable=yes audit=no Now you should have ZTDNS running! In a rare situation where you experience unexpected connectivity issues for some application, please restart the application. If the issue persists, please reboot the device. Disable ZTDNS ZTDNS is a powerful lockdown feature. In case you lose network connectivity due to misconfiguration, you can disable ZTDNS to restore your network connectivity. In an administrator command prompt, run: netsh ztdns set state enable=no audit=no Note: ZTDNS is currently in Public Preview and is intended for evaluation and feedback only. Do not deploy in production environments. Breaking changes may occur before General Availability (GA). Check out the next blog post Troubleshooting Zero Trust DNS for information on ZTDNS logs, sharing feedback and bug reports with the team. Join Me at RSAC 2025 I am excited to share that I will be attending the RSA Conference 2025! If you are planning to be there, stop by Microsoft booth N-5744 or Microsoft Security Hub and ask for Aditi Patange to discuss how ZTDNS can enhance your organization's security posture. Securing the Present, Innovating for the Future Security is a shared responsibility. Through collaboration across hardware and software ecosystems, we can build more resilient systems secure by design and by default, from Windows to the cloud, enabling trust at every layer of the digital experience. The updated Windows Security book is available to help you understand how to stay secure with Windows. Learn more about Windows 11 and Copilot+ PCs. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
QOS and MTU settings
A contractor has asserted that latency delays are caused by a "misconfiguration" of the hardware of certain machines that produces flooding of the network with bad packets. They have asserted that they find this when checking out a new site. Is this also associated with a Quality of Service setting on a site's server if it would then release such large number of packets to the network? Does this also require careful adjustment of the MTU (Max. Trans. Unit) settings on each base server? (MS Server setting???) Or does the server simply transmit all the packets it receives from networked machines?
Untagged VLAN - Server 2025 Hyper-V
Hi, I have a strage issue and not finding a solution. Using Server 2025 with two node Hyper-V cluster. Most of the machines using VLANs which works fine. Some machines using no VLAN config. Which usually means the "Access VLAN 1" regarding our switch configuration. With Server 2019 this worked fine. With Server 2025 same NIC port, same server/NIC hardware "Untagged" VMs don't get any network connection. If I add a second NIC to the VM "Untagged" the NIC get immidiatly an IP address and has a proper connection. If I remove the first NIC, the second NIC stop working. It looks like something has changed with Server 2025 (maybe already with Server 2022). Do you have any idea what kinde of problem I have found? Thanks Jack
