At the moment PPPoE is broken in Windows Server 2016 over RRAS.
It would be great if this could be solved.
Till yet we're using Windows Server 2012. But we would like to upgrade but can't 'cause RRAS is broken.

Comparing the documentation of DirectAccess for 2012 with other products, even DirectAccess 2008, I see that it lacks some in-depth insights that an Admin needs to be able to deploy and manage the component effectively.
for example, I could not find a TechNet article describing in details, what happens from start to finish when a resource is being accessed through direct access:
1. how is the NAT64 working? how does NAT64 translates address and which IPv4 address translates to which IPv6 and vice-versa? how does the component come up with those connection security rules in GPOs based on admin input in the config(which configuration part has affect on which GPO setting)?
2. manage-out. how does that work and what are the caveats?
3. the lifecycle management: how do you migrate from 2008 or UAG to 2012 and eventually 2016? how do you manage expired certificates or swap of the root certificate without the client down time?

Comparing the documentation of DirectAccess for 2012 with other products, even DirectAccess 2008, I see that it lacks some in-depth insights that an Admin needs to be able to deploy and manage the component effectively.
for example, I could not find a TechNet article describing in details, what happens from start to finish when a resource is being accessed through direct access:
1. how is the NAT64 working? how does NAT64 translates address and which IPv4 address translates to which IPv6 and vice-versa? how does the component come up with those connection security rules in GPOs based on admin input…

"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.

"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…

Just like to ask Microsoft if they could make a secure server to server communication protocol, that use say 44443, that is a strip-down TCP that don't use the 3-hand system (more like secure UDP with error correction). That allows each product to talk to each other, using a PKI, or on-prem ADCS certificate.
But this communication should be base on Control+Data info
were each product can list all the control-command(standards) that it accepts.

What is this for, you ask:

So it will be easy for all products to talk to each other without complicated configuration.

eg:

you install AD, DNS, DHCP on ad.local
you install File-server on files.local
you then install ADCA on subca.local
you then install exchange 2017 to mail.local
you then install Skype 2017 on phone.local
you then install SharePoint 2017 to sp.local
you install other products.

Adding these machine to AD is very simple. very-good
letting each program communicate to each other is not very simple. very-bad.

I would like to have skype look into AD and see the mail server and configure itself to use that mail server, or allow me to tell it to use that server as its mail server. Let it talk to the mail server to ask any of it what it needs. If i install another Skype server let it see the first one, and ask me if i and to replace/add to/ignore/etc.. so that it can auto configure itself accordingly.

I would like exchange, and the other products do the same.
They must use the userbase from AD or any AD OU i tell it to use. No more long hours of powershell to configure a simple lab/production system.

Thanks.

Hola,

(if that clear, read until reach bottom of this post)

Just like to ask Microsoft if they could make a secure server to server communication protocol, that use say 44443, that is a strip-down TCP that don't use the 3-hand system (more like secure UDP with error correction). That allows each product to talk to each other, using a PKI, or on-prem ADCS certificate.
But this communication should be base on Control+Data info
were each product can list all the control-command(standards) that it accepts.

if the customer wants to upgrade or change the CA, he needs to bring in all the remote computers and do a GPO refresh on-premises; otherwise the moment the new CA is input into the configuration of DA server, the clients which are still using the old CA are kicked out of DA.

we need a process for such transition, in case of an expired or compromised CA, to let the clients smoothly transition into the new CA without the requirement of them comping onsite for a GPO refresh. I would say enable the addition of Multiple CA rather than the single CA that is in place right now.

if the customer wants to upgrade or change the CA, he needs to bring in all the remote computers and do a GPO refresh on-premises; otherwise the moment the new CA is input into the configuration of DA server, the clients which are still using the old CA are kicked out of DA.

we need a process for such transition, in case of an expired or compromised CA, to let the clients smoothly transition into the new CA without the requirement of them comping onsite for a GPO refresh. I would say enable the addition of Multiple CA rather than…

it is hard to tell which IPv6 interface DirectAccess is using to connect to the infrastructure. now you have to run netsh on httpstunnel and teredo and 6 to 4 to have some "educated guess" about which one is the one chosen for DA.

we should be able to easily identify which interface (native or tunnel) is being utilized for DA communication on the client. the server GUI shows it already.