It's like the RDG didn't even try to redirect the traffic there were no packets being generated. This was capturing on the RDG box on all interfaces. When we connected to the original SHs on the other subnet, we did not see any traffic from the RDG to the SHs. We tested adding a session host in the same subnet as the RDCB, and when we connected to that, we saw traffic from the RDG to the SH that began with some RPC stuff (135 followed by high-numbered port) and then TCP 3389. ![]() ![]() That pointed strongly to an issue with the RDCB. We ruled out issues with the RDG by calling up mstsc and connecting to the session host using the RDG FQDN as a gateway. In our scenario, we had a single server with RDWeb, RDG and RDCB roles, connecting to RD session hosts in another subnet. In addition to we also got bitten by rule required in the opposite direction to expected. Maybe our firewall setup forces us to be a lot more granular than most but explicitly saying which direction traffic would save us a lot of time and trouble trying to figure out what's getting blocked. I opened it both ways but you might only need RDCB -> SOFS on RPC. * If you are using an external storage solution for your User Profile Disks (like SOFS), you need to open RDCB -> SOFS on RPC (tcp 135 random port range). (The document implies that you only need RDCB -> HV Hosts.) If RPC is only open RDCB -> HV Hosts, you can add the Hyper-V hosts to your deployment but when you try to create a VDI collection, it won't find your template VMs. * RPC (tcp 135 random port range) needs to be open BOTH WAYS between the Hyper-V hosts and the RD Connection Broker server(s). In other words, "open this port on this component" isn't sufficient. Our firewall setup requires us to explicitely define all rules as. I ran into problems relying on this document when implementing VDI on Hyper-V in a locked down environment. This document doesn't really address the concept of directionality and doesn't take into account the use of a dedicated file server for User Profile Disks. UDP|TCP 389 LDAP - Used with per-user CALs against Active Directoryįrom a proxy standpoint, the regkey HKLM\Software\Microsoft\TermServLicensing\lrwiz\Params shows the Microsoft service that the RD LS communicates with.How to configure which ports (if need to set to specifics) TCP 443: Communication over the internet to the Microsoft Clearing House.TCP 49152 - 65535 (randomly allocated) - This is the range in Windows Server 2012, Windows Server 2008 R2, Windows Server 2008.TCP 1024-65535 (randomly allocated) Used for RPC For Windows Server pre-2008 (see next line).TCP 135 - RPC for License Server communication and RDSH.The ports used have not changed in Windows Server 2012 | R2. Information for Terminal Server in Windows Server 2008 is at TCP 389|636: Active Directory communication.TCP 5504: connection to RD Connection Broker for centralized publishing.If RD Web Access is on a perimeter network.TCP|UDP 3389: RDP (NOTE: Firewalls that have directional UDP analysis, such as TMG, require UDP "Send Receive" configured in the UDP protocol).For internal traffic from the Gateway and the Internal Remote Desktop resources.UDP 1812, 1813: If NPS Server is being used.TCP 21: If using FTP for Certificate Revocation List (CRL).TCP 80: If using HTTP for Certificate Revocation List (CRL). ![]() TCP|UDP 389: If using LDAP for Certificate Revocation List (CRL).TCP|UDP 53: Internal resource name resolution, DNS. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |