Remote Desktop Services Health Monitor Fails after 2008R2 Windows Updates Applied

I've been having the same problem in my environment. After doing some monitor logging, I determined that there's a new RECV string coming back from the server...

In the UI, the

recv

value should be

\x03\x00\x00\x13\x0e\xd0\x00\x00\x124\x00\x02\x09\x08\x00\x02\x00\x00\x00

(in my situation)

The ltm config for the monitor is

ltm monitor tcp MONITOR_NAME {
    defaults-from tcp
    description "Windows Server 2008 R2 RDS Monitor (recv str is not f5 specified, but found from checking monitor traffic logging)"
    destination *:*
    interval 30
    ip-dscp 0
    recv \\x03\\x00\\x00\\x13\\x0e\\xd0\\x00\\x00\\x124\\x00\\x02\\x09\\x08\\x00\\x02\\x00\\x00\\x00
    send \\x03\\x00\\x00\\x13\\x0e\\xe0\\x00\\x00\\x00\\x00\\x00\\x01\\x00\\x08\\x00\\x03\\x00\\x00\\x00
    time-until-up 0
    timeout 91
}

(Note: if it doesn't work, try replacing the double slashes with single slashes. My box has a strange habit of decoding special characters when I save changes)

If that doesn't work, the best way to figure out what you need is to enable monitor logging and watch the log for the RECV string.

• Open the pool that is having the problem (let's call it RDP_POOL)
• Make sure the monitor is active on the pool (let's call it RDP_MONITOR)
• On the

  Members

  tab in the pool settings, click on one of the members (let's call it 10.0.0.1:3389)
• Enable the checkbox for

  Monitor Logging

• Open an SSH session (I use Putty to connect) to the device and log in to the shell.
  • Run the command

    cd /var/log/monitors

  • Run the command

    ls -l

  • Look for the file referencing your pool and member (most likely in our example it'd be something like

    _Common_RDP_MONITOR__Common_10.0.0.1_3389.log

    )
  • Run the command

    tail -f FILENAME

    (where FILENAME is the log filename)
  • It may be visible immediately, but you should see where the monitor sends the request to the server (and you'll see the

    send

    string), and you're looking for the

    recv

    string that comes back.
  • Take that

    recv

    string and update the monitor and see if the pool member(s) show up green again.
• Go back in and disable the monitor logging for that member so you don't have excessive logging filling up space.

This should help figure it out. If your log file ever looks like it's not updating, delete the file and remove the monitor from the pool and re-add it. I've found that will kick it back off again.

The problem is the 13th byte changed from x01 to 0x09. The 12th byte value of x02 indicates the server is sending a RDP Negotiation Response and by the protocol requirements must always remain x02. However, the 13th byte is a bit mapped flag.

 

Before the patch, 2008R2 response with x01 indicated only "EXTENDED_CLIENT_DATA_SUPPORTED." The patch added x08 to the mask (indicating also "RESTRICTED_ADMIN_MODE_SUPPORTED") for a total flag value of x09.

 

This flag is explained at: https://msdn.microsoft.com/en-us/library/cc240506.aspx

 

Simply changing it to match the new flag does not future-proof the monitoring for additional flag changes. Also, it seems to me that monitoring that the flag remain exactly the same provides no benefit to confirming the health of the RDP service. As such, I would recommend changing the receive string to only confirm the first 12 bytes like so: \x03\x00\x00\x13\x0e\xd0\x00\x00\x12\x34\x00\x02

 

An alternative to provide future proofing would be to replace the 13th byte with a wildcard character but I'm not sure how to specify that on the F5.