Some implementations of TLS 1.0 did not properly validate the padding as required by the TLS specification. This led to a situation in which the POODLE bug could be leveraged against TLS 1.0, despite the fact that it should be secure against the attack. Later versions of TLS (i.e. 1.1 and 1.2) are inherently secure against POODLE and other padding oracle issues because they authenticate the encrypted message (CBC-then-MAC) rather than authenticating the plaintext (MAC-then-CBC).

As far as I know, the only major implementations affected are in equipment from F5 Networks, A10 Networks, and Cisco. The SSL Labs scanner checks for the bug, but it can only target internet-facing IPs. The Windows SSL stack, as far as I can tell, properly implements the padding checks in TLS 1.0 and therefore isn't vulnerable to the TLS variant of POODLE. As such, you shouldn't need to do anything.

Some implementations of TLS 1.0 did not properly validate the padding as required by the TLS specification. This led to a situation in which the POODLE bug could be leveraged against TLS 1.0, despite the fact that it should be secure against the attack. Later versions of TLS (i.e. 1.1 and 1.2) are inherently secure against POODLE and other padding oracle issues because they authenticate the encrypted message (CBC-then-MAC) rather than authenticating the plaintext (MAC-then-CBC) (EDIT: That bit was wrong, see Thomas Pornin's comment below)

As far as I know, the only major implementations affected are in equipment from F5 Networks, A10 Networks, and Cisco. The SSL Labs scanner checks for the bug, but it can only target internet-facing IPs. The Windows SSL stack, as far as I can tell, properly implements the padding checks in TLS 1.0 and therefore isn't vulnerable to the TLS variant of POODLE. As such, you shouldn't need to do anything.