none
RAIL: Remote Application Integrated Locally RRS feed

  • Question

  • The MS-RDPERP.PDF documentation deals with the Remote Application feature.
    One information is missing: the name of the static virtual channel.
    Of course we may assume the channel name is 'rail'. But when analysing a RDP client network traffic, three separate static channels are actually announced: rail, rail_ri and rail_wi.
    Why 3 channels? What is the actual purpose of each of them?
    Thank you

    Vincent

    Thursday, February 24, 2011 3:39 PM

Answers

  • Vincent,

     

    Regarding the RAIL channel negotiation issue you reported, RAIL clients must initiate the Client MCS Connect Initial PDU as specified in MS-RDPERP section 3.2.5.1.1, and MS-RDPBCGR section 3.2.5.3.3.

     

    With Microsoft implementations, i.e. a Windows server or client, the name “RAIL” needs to be used for the static virtual channel (see the following Windows behavior).

     

    MS-RDPERP <23> Section 3.2.5.1.1: Windows implementations use RAIL as the name of the virtual channel.

     

    Note that other implementations may feel free to use their own name.

                  

    The extra virtual channels rail_wi and rail_ri (observed in Windows-to-Windows traffic) should only be created while establishing a local RAIL connection to a local Windows XP RDP server. When connecting locally to a Windows XP RDP server, all alternate secondary PDUs are also sent over these custom virtual channels. This XP mode feature is specific to local virtual machines and was internally introduced only for Virtual PC scenarios. As a result, these channel names do not have any protocol significance in the current RDP protocol set.

     

    It has been determined that there is a code defect at the client side (e.g. in Windows Vista and Windows 7) whereby the client includes all the aforementioned VC names in the array of channel definitions to be negotiated.

     

    A product bug will be filed so this can be reviewed for an eventual fix in future Windows releases. Note that we may not provide a quick patch on this issue since it is not protocol significant.

     

    Thanks again for reporting this issue to Microsoft.

     

    Regards,

    Edgar

    Thursday, March 17, 2011 9:38 PM
    Moderator

All replies

  • Vincent,

    Someone from our team will follow-up with you shortly in regards to your issue.

     

    Friday, February 25, 2011 3:18 PM
  • Vincent,

    I am researching this and will follow-up as soon as I have the answer.

    Thanks,

    Edgar

    Friday, February 25, 2011 9:44 PM
    Moderator
  • Vincent,

    While researching this, I need clarification on the context of your RDP connection.

    Can you confirm whether you are establishing a RemoteApp connection to a Windows  XP server?

    Thanks,

    Edgar

     

    Wednesday, March 9, 2011 7:59 PM
    Moderator
  • Edgar

    The network trafic was captured between a Win7 and Win2008R2.

    Regards

       Vincent

     

    Thursday, March 10, 2011 1:04 PM
  • Vincent,

    Can you send the network trace to this email alias: dochelp < at > microsoft.com so I can have a look?

    Please mention the title of this thread, and address the message to my attention.

    Regards,

    Edgar

    Friday, March 11, 2011 4:06 PM
    Moderator
  • test
    Regards,
    Tuesday, March 15, 2011 8:41 AM
  • Vincent,

     

    Regarding the RAIL channel negotiation issue you reported, RAIL clients must initiate the Client MCS Connect Initial PDU as specified in MS-RDPERP section 3.2.5.1.1, and MS-RDPBCGR section 3.2.5.3.3.

     

    With Microsoft implementations, i.e. a Windows server or client, the name “RAIL” needs to be used for the static virtual channel (see the following Windows behavior).

     

    MS-RDPERP <23> Section 3.2.5.1.1: Windows implementations use RAIL as the name of the virtual channel.

     

    Note that other implementations may feel free to use their own name.

                  

    The extra virtual channels rail_wi and rail_ri (observed in Windows-to-Windows traffic) should only be created while establishing a local RAIL connection to a local Windows XP RDP server. When connecting locally to a Windows XP RDP server, all alternate secondary PDUs are also sent over these custom virtual channels. This XP mode feature is specific to local virtual machines and was internally introduced only for Virtual PC scenarios. As a result, these channel names do not have any protocol significance in the current RDP protocol set.

     

    It has been determined that there is a code defect at the client side (e.g. in Windows Vista and Windows 7) whereby the client includes all the aforementioned VC names in the array of channel definitions to be negotiated.

     

    A product bug will be filed so this can be reviewed for an eventual fix in future Windows releases. Note that we may not provide a quick patch on this issue since it is not protocol significant.

     

    Thanks again for reporting this issue to Microsoft.

     

    Regards,

    Edgar

    Thursday, March 17, 2011 9:38 PM
    Moderator