Hi all,

I understand there is an issue with Windows Server 2019/Windows 10 1809 however I was wondering if Microsoft are aware of any problems regarding the Firewall rather than the systems handling of user files.

Recently I setup a Server 2019 VM (1.5GB Dynamic RAM, 2 Allocated Cores, 36GB Drive space, 3GB NIC Team) and installed the NPS and RDS Gateway role onto it however I noticed that despite the NPS role adding the standard firewall rules for port 1813 and 1812 they do not seem to be working.

I have confirmed that with an exception allowing port 1812 through or disabling the firewall allows authentication requests to reach the NPS server however when these are removed and the default rules are left they are blocked.

I have performed an SFC scan and DISM scan/repair however no issues have been detected
I have also spun up a new Server 2019 and Server 2016 server to compare and the 2019 server has the same issue whilst the 2016 server has no problems with just the default rules and no exceptions/extra.

If anyone has any suggestions or information I would be extremely great-full as currently I'm not sure what seems to be the cause

"netsh trace" and/or NetEventPacketCapture lacks capable packet filtering. A lot of secure and change managed environments do not [easily] allow the installation of packet capture tools for collecting network data, like Wireshark (or the now defunct netmon and Message Analyzer).

The two built-in packet capture tools in Windows, "netsh trace" and NetEventPacketCapture, can only filter packets by IP address, MAC, and protocol. This makes collecting a targeted trace, sometimes needed when collecting traces on sensitive networks or when other data floods the ETL, impossible.

This is a request to add, at a minimum, the ability to filter packets by TCP port and UDP endpoint. Ideally, Windows inbox packet filtering should be on par with the industry standard tcpdump(*nix)/npcap(Wireshark for windows) filter format.

When Server 2016 DNS Server has a delgation within a primary zone, CNAME records in that delegation result in queries to the delgation's name servers, not forwarders / root hints.
For example:

Primary zone: one.example
Delegation: foo.one.example, with nameserver ns.bar.com

In that delegated zone, there exists a record:

baz.foo.one.example IN CNAME other.two.example

two.example's zone, hosted by ns.somethingelse.com, has a record:
other.two.example IN A 1.2.3.4

From a client pointed at the DNS server, query baz.foo.one.example.

I would expect the server to query ns.bar.com for baz, receive a reply of other.two.example, and then query either two.example's nameserver, or use the default forwarders to do the same, resulting in a recursive resolution passed back to the client of 1.2.3.4.

What actually happens, in Server 2016, is that only the CNAME is returned. With debug logging enabled, the DNS server issues a query to ns.bar.com for other.two.example, and of course gets a REFUSED response.

In Server 2012 R2, with the same configuration, baz.foo.one.example is resolved recursively to 1.2.3.4.

I'm pretty sure the new behaviour is incorrect?

Thanks,
Rob

The new cmdlets for DNS policies in particular have inconsistent and downright broken support for -WhatIf and -Verbose.

Example:

Add-DnsServerClientSubnet -cn MyDC -Name 'Whatever' -IPv4Subnet 10.0.0.0/32

That works if you explicitly add -WhatIf. But if I make the call inside an advanced function that SupportsShouldProcess and call the outer function with -WhatIf, the preference will NOT carry over. In order to do that, I have to use -WhatIf:$WhatIfPreference.

The same is true with -Verbose, having to use -Verbose:$VerbosePreference because it won't inherit it.

This is true on the cmdlets for:
- Client Subnets
- Zone Scopes
- Query Reoslution Policies

Additionally, -ErrorAction is seemingly ignored; they all throw regardless of the setting, forcing the use of try / catch.

The worst gaffe is Get-DnsServerClientSubnet. It has no -WhatIf support, which is normal for a read-only Get- cmdlet, but if $WhatifPreference is $true, it uses it! It won't return the values. And since there is no -WhatIf parameter to override, I'm having a **** of a time getting around this.

So far I've tried explicitly setting $WhatIfPreference to $false before calling it but it seems like that's not working. Still experimenting.

The MMC console based management of windows server is still unchanged since server 2003. These are the things that bother me:

- Window size is not saved. have to maximize everytime the window is opened
- Treemenu on the left is collapsed every time the window is opened
- Menu window on the left is very narrow, have to extend it every time the window is opened
- Cant edit IP address range exclutions (you have to delete and recreate every time)
- Cant edit reservations IP address

Following features would be great to have:

- Right click on a client and copy MAC address (for dhcp reservations)
- Under address leases, show a column to see at what time a specific IP address has been issued. i know you can see the lease expiration and calculate back the issued time with the lease duration, but its inconvenient
- While were at it, a possibility to export/import reservations from specific scopes. Something like a "move-reservations-to-new-scope" feature. This would make migrations of IP ranges much more comfortable.

Nowadays we try to work as less as possible with static IP addresses on the client and use DHCP reservation instead. This way, we do get the advantage of DNS registration and we dont have to touch the devices (printers, APs, and so on...) on a subnet change.