William

My feedback

  1. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Networking  ·  Flag idea as inappropriate…  ·  Admin →
    William commented  · 

    How does that work when Group Policies are features of domain-joined computers? If the computer isn't joined to the domain, the User Configuration section of Group Policy isn't going to be applied either, unless you're configuring it manually on each computer, in which case just use netsh.

    If you're trying to configure unmanaged devices using Group Policy, you're doing it wrong.

  2. 85 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    25 comments  ·  Networking » Firewall  ·  Flag idea as inappropriate…  ·  Admin →
    William commented  · 

    Definitely a bug with Windows Server 2019. I upgraded a Windows Server 2016 server hosting the NPS role which worked perfectly fine pre-upgrade. After the upgrade completed, NPS stopped processing authentication requests.

    I checked the NPS event log and noticed a conspicuous lack of entries for connection attempts. After confirming the service was running, I tried turning the Windows Firewall off and watched it spring to life. I turned it back on and noticed it stopped. After checking the rules, I discovered the default rules exist but they didn't appear to be working. After turning on failure logging, you can clearly see the Windows Firewall dropping the packets on port 1812 from the RADIUS clients, despite the rule existing to allow it.

    As others have said, creating a manual rule to allow port 1812 fixes the problem but it shouldn't be necessary.

    The rule appears to have been created properly as it is bound to the service host and configured to allow traffic for the IAS Windows service, but for some reason, it's not working.

    William supported this idea  · 

Feedback and Knowledge Base