none
Task Scheduler -- Possible to Trigger event on local Unlock but not Remote Desktop login?

    Question

  • This is intended as a Task Scheduler question, not a networking question, but I welcome help on either side of this issue:

    I believe my core question is how do I set a trigger that only activates on a local login but not on a Remote Desktop login? I had thought that was the difference between "On workstation unlock" (local only) and "On connect to user session" (local or remote), but this appears not to be the case, as even "On workstation unlock" is triggered by a Remote Desktop login. Details follow.

    I have a computer with dual NICs, each pointing to a different unrelated Internet connection. I am operating on the assumption that I can only have one functional gateway at a time (if this is a bad assumption, I would need to know how to route traffic to a NIC based on application or port #, not just IP#, which as far as I can tell is not possible in Windows). Both are relatively slow Internet connections, but one is a faster download connection (slower upload) via a randomly-assigned dynamic IP#. The other is a faster upload (but slower download) and has a static IP. When I'm sitting at the computer, I want to use the faster download for better Internet performance. When I'm remote, I want to access the computer using the connection with the static IP and so that I get the benefit of the faster upload speeds sending the screen images out (in most cases, the remote connection will be much faster than on this computer, so the performance differences between the two connections is relevant -- the faster upload makes a real difference to remote usability).

    I have successfully set up Task Scheduler to change the Route instructions to properly assign the gateway to the respective NIC for local use, but they don't work properly for remote use. Specifically, a few minutes after the Workstation locks, Task Scheduler runs a script that sets the Gateway to the static IP NIC. That part's good and confirmed working. And if I unlock the computer locally, it runs the script that sets the Gateway to the faster download dynamic IP NIC. Also good and confirmed working.

    The problem is that if connect remotely via Remote Desktop, it initially connects over the fast-upload static IP NIC as it should, then this connection apparently activates the "On workstation unlock" trigger, which resets the gateway to the other NIC and prevents my connection and completely blocks any future connection attempts (because incoming requests for Remote Desktop connection are over the static IP, and response go out over the registered gateway, now reset to the dynamic IP).

    I haven't been able to find anything that clearly explains the difference between "On workstation lock/unlock" and "On connect to/disconnect from user session". What is the difference and is there any option to trigger ONLY on local workstation login, but NOT on a Remote Desktop login?

    Monday, January 23, 2017 3:24 PM

All replies

  • This is not a perfect solution and doesn't answer the core question about distinguishing between a local and remote login, but the following additional code in the script might work:

    Set TerminalServer=False
    wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TerminalServiceSetting Get TerminalServerMode>%TEMP%\tsmode.txt

    Findstr "0" %TEMP%\tsmode.txt>NUL

    If ERRORLEVEL 1 Set TerminalServer=True
    Del %TEMP%\tsmode.txt

    echo You are accessing the computer remotely: %TerminalServer%
    echo.

    If /i "%TerminalServer%" == "True" (
     echo This is a Remote Desktop session, so you cannot
     echo change to network gateways.
     echo.
     goto :exit
    ) else (
     echo This is not a Remote Desktop session, so go ahead
     echo and change the gateway if you want.
     echo.
    )

    [then existing code to change network goes here]

    I also added a question, so it stops to ask the user if it should change, ensuring it never autochanges and breaks the remote connection.


    Colin

    Tuesday, January 24, 2017 7:51 PM
  • Hi,

    This issue is more related to script, I would help you move it to script forum for more professional help.

    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. Thank you for your understanding.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, January 25, 2017 9:17 AM
  • This is one of those bad design situations.  It will not be able for a normal user to run this code as it requires full administrator privileges.

    I suspect this is a home computer not connected to a domain as this would be a disaster in a domain.

    To route traffic correctly on a system like this we would normally set up routes outbound as needed and the gateway would then be automatically and dynamically selected.

    The place to start is to define exactly why you are doing this.  What is it intended to accomplish.  This will tell us how to configure the system for the desired behavior if it is possible to do so.


    \_(ツ)_/

    Wednesday, January 25, 2017 10:54 AM
  • Hi,

    This issue is more related to script, I would help you move it to script forum for more professional help.

    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. Thank you for your understanding.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    This issue is absolutely NOT related to script. I came up with that as a crude work-around to my question so added it here in case anyone else is similarly stuck -- better than nothing. My question is about Task Schedule Triggers -- what is the trigger option that will react based on local login, but not remote login. There was also a secondary possibility asked about in the original post around the underlying networking issue with a multihomed system and Remote Desktop access where both NICs have Internet access.


    Colin

    Wednesday, January 25, 2017 11:36 AM
  •  There was also a secondary possibility asked about in the original post around the underlying networking issue with a multihomed system and Remote Desktop access where both NICs have Internet access.


    Colin

    I agree. It is not a scripting issue but it is also not a trigger issue.   The login trigger always executes and you can use a script to determine if the login is local or remote.

    In an RDS environment I would dual home the system or, if this is just about browser access to the Internet I would use a proxy server to route browser traffic.

    Setting routes would also be a permanent way to direct traffic to the appropriate gateway.


    \_(ツ)_/

    Wednesday, January 25, 2017 11:42 AM
  • @jrv, thanks for jumping in. I suspect you are right that routing is the right way to do this, but I didn't think it was possible to set up routes based on anything other than IP#. The code solution does require admin privileges, but as noted in the original post, this is all executed by a Task Schedule trigger, so there is no UAC issue.

    This computer is connected to a Windows Server 2012 R2 domain (albeit a small one with only a few computers on it) and physically secured, but it also has its own dedicated consumer grade DSL connection, which offer significantly faster download performance over the shared T1 used by the domain computers. But the T1 offers much better upload performance and lower latency. The shared T1 is what I need to use for the Remote Desktop connection. The NIC with the T1 gateway is also the NIC that connects to the rest of the network for network services. We are not running a Remote Desktop Gateway on a Server. Instead incoming RD traffic is routed by port to this computer -- it's the only one that needs remote access on the network.

    Ideally, I could lock all RD traffic on this computer (and a few other less important applications that break if the route changes) to always over the T1 and leave the main Gateway to always be the DSL connection, but I haven't found that there is a way to do that. You can't set it via the ROUTE command, because those are only based on IP#, which doesn't help here. Maybe there's a proxy server option or some other way to set it for the application. Do you know of any other way to do this?

    Because I couldn't find any of those solutions, I turned to the Task Scheduler which I could easily set to flip the gateway to use the DSL when user logs in locally, and flip back to the T1 when the workstation locks (user is away). This approach would be fine (still not as good as per-application routing, because of those other apps that break, but that's a tolerable downside), except that it seems the Task Scheduler trigger doesn't distinguish between local and remote connections using "On workstation lock/unlock" even though it seems like that's the key difference between that trigger and "On connect to/disconnect from user session." This means that the remote login via Remote Desktop causes the same switch to the DSL gateway, which instantly severs the RD connection. Hence the added script above, which at least adds that check to the code run by the Task Scheduler trigger, and then prevents it from running if being accessed remotely.

    Any ideas or suggestions?


    Wednesday, January 25, 2017 12:02 PM
  • We don't change the router.  WE would just set the local routing table.

    at a cmd prompt:

    route print
    route /?

    Routes are specified to network destinations just like on a router.


    \_(ツ)_/


    • Edited by jrv Wednesday, January 25, 2017 12:25 PM
    Wednesday, January 25, 2017 12:24 PM
  • Place routes by destination IP or IP range and the router will manage the communication as needed.  Find the target used by the application and set that route to use the required gateway.  With this all applications will always get the correct gateway for their target request.


    \_(ツ)_/

    Wednesday, January 25, 2017 12:30 PM
  • route add 10.0.0.0 mask 255.0.0.0 192.168.0.1 metric 2

    route add webservices.example.com mask 255.255.255.255 10.11.12.13

    https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_tcpip_pro_addstaticroute.mspx?mfr=true


    \_(ツ)_/


    • Edited by jrv Wednesday, January 25, 2017 12:34 PM
    Wednesday, January 25, 2017 12:32 PM
  • Place routes by destination IP or IP range and the router will manage the communication as needed.  Find the target used by the application and set that route to use the required gateway.  With this all applications will always get the correct gateway for their target request.


    \_(ツ)_/

    Right, ROUTE is what I use to change the gateway, in fact. But ROUTE only routes based on IP#, as far as I know, which I don't think helps us here. I want ALL Internet traffic on this computer except for Remote Desktop (as the server), an SSH client, and a Citrix ZenApp client, to go over the DSL. And for those other 3 services, they should go over the T1 (the Remote Desktop server function is the only one that really matters of those, if they others flip to going over DSL when the user is at the computer, that's acceptable, it's just that they will be disconnected by the gateway change and need to be reconnected, a minor annoyance). Because Remote Desktop client could be coming from various dynamic IP#'s, there's no way to use ROUTE for them, as far as I know.

    What do you think?


    Colin

    Wednesday, January 25, 2017 1:31 PM
  • In an RDS environment I would dual home the system or, if this is just about browser access to the Internet I would use a proxy server to route browser traffic.

    I do view this as a multihomed (dual homed) system. I could use ROUTE to change the metric easily enough and prioritize which NIC is the current primary gateway, but the traffic I need to direct is really application-based, not IP# based.

    Windows doesn't seem to have a straightforward way to route traffic by application or port # (e.g., port 3389 for RD).


    Colin

    Wednesday, January 25, 2017 1:35 PM
  • ROUTTE can route based on IP or DNS name.

    It only sends connections based on the requested target address.  We set up the host to route to the default network then add routes for specific application targets so they will always use the correct gateway and all else remains the same.  This is what we want in an RDS setting.

    RDS routes are specific to the incoming connection.  RROUTE cannot change how they work and cannot move the connection after it has been established.   We can add a second IP to the I/F and specify that that IP is from the second gateway.  We would then use this IP to connect to the RDS server but we would need to be sure the IP is discovered via DNS and that DNS supplies this IP.  The issue then becomes not allowing the IPs to be discoverable on both gateways.  You need to be sure that the inbound connections always only originate from the correct external network.  The gateway cannot route traffic to the RDS on the disqualified network.  This is done using network translation on the router which it sounds like you have done.  Port forward the RDS port on only the preferred gateway.  All RDS traffic will always flow on the gateway.  All Internet traffic will flow on the Internet gateway if that is the default route on the server. Any applications that you want routed differently would get routes through the non-default gateway based on target host names.

    I suspect the ZenApp client is used to connect to only a few servers so that can be forced over the required gateway with ROUTE. The SSL client can also have its targets force routed.


    \_(ツ)_/

    Wednesday, January 25, 2017 1:49 PM
  • Windows doesn't seem to have a straightforward way to route traffic by application or port # (e.g., port 3389 for RD).


    Colin

    ALL routers route by destination. You are thinking of a proxy which can be application directed such as ISA server. ISA can reroute traffic by source application ID or outbound port.

    Again - your RDS connection will always be on the gateway it connected through and it cannot be changed no matter what you do.

    Just add outbound routes based on the applications target server name.


    \_(ツ)_/

    Wednesday, January 25, 2017 1:54 PM
  • ALL routers route by destination. You are thinking of a proxy which can be application directed such as ISA server. ISA can reroute traffic by source application ID or outbound port.

    Again - your RDS connection will always be on the gateway it connected through and it cannot be changed no matter what you do.

    Just add outbound routes based on the applications target server name.

    You wrote "your RDS connection will always be on the gateway it connected through and it cannot be changed no matter what you do." If by that you mean that if the incoming RDS connection is via the T1 NIC that responses will be over that NIC regardless of the GW setting on that computer, that is definitely not true. I can reproduce this problem 100% of the time. Incoming connection is over T1, properly routed to computer for initial response, Gateway on the computer changes from T1 to DSL, RD connection lost and can't be recovered until GW is set back to the T1 NIC. I believe this is a known issue with multihome RDS usage. I just searched for the link where I've seen this exact problem defined, but couldn't find it just now. 

    Note that everything I've described in this entire post relates purely to changes on the Remote Desktop workstation (the RDS server, just running Windows 10 Pro). I think you may have thought I was talking about changes to a router. The only router change is outside of this issue where traffic on the T1's router is set to route all incoming traffic on port 3389 to this workstation.

    I also think I may be missing your point, because I keep thinking -- this isn't a ROUTE command issue, because that only works with IP#s.

    When you say, "Just add outbound routes based on the applications target server name," how can I know the "applications target server name" for an incoming Remote Desktop connection? That could be coming from anyplace, including a mobile device. So this can't be added to the ROUTE table, can it? What am I missing?


    Colin

    Wednesday, January 25, 2017 4:45 PM
  • That is what I posted.  You cannot change the route after a connection is established.  Outbound connections to web sites will reconnect and use the new route but inbound connections will be lost.to anyone then you have to use the same gateway for both serverss

    I m talking about the internal Windows routing table.  Every Windows system is a router.

    I recommend that you get a consultant that is certified in networking to help you with this.  You do not have enough knowledge about networking to understand what you need to do and I see no point in repeating the same instructions.  Either you understand hw to manage the Windows routing table and how it works or you don't.

    As far as the app server goes it will work the same way.  On the app server it will connect on the gateway that you select fo r it except if it is a public server that connects.  If you contact Citrix they will help you set up the app server to publish the apps through a specific gateway.


    \_(ツ)_/

    Wednesday, January 25, 2017 5:42 PM
  • That's insulting. I'm not paying someone to answer a generic question about Windows Task Scheduler (is it possible to trigger a task based on local login but not based on remote login?) or how to route Windows Remote Desktop traffic based on something other than IP#. These should have a factual answers that are universal attributes to Windows and have nothing to do with my specific situation. Therefore, it is reasonable to expect to find an answer from a Windows expert.

    I am quite clear on the networking issues here. I apologize if I have not been clear on my description of the problem, but I feel I have been, multiple times.

    You are trying to solve a problem I don't have. You wrote, "You cannot change the route after a connection is established.  Outbound connections to web sites will reconnect and use the new route but inbound connections will be lost"

    Again, I don't have an issue with web access. I only have an issue with breaking Remote Desktop access, which I have solved with the kludgey work-around that I posted above. And it is absolutely a fact that I can reproduce 100% of the time, from any remote location -- client connection comes in over the T1 line and is then lost when the gateway changes to DSL on the host computer, even though the NIC on the subnet with the T1 connection is still fully accessible from this host computer and all LAN traffic to and from the host on this NIC/subnet continues to work fine (just no traffic that would need to go out over the T1 gateway). I also know why this happens -- the host computer sends all response traffic to the Remote Desktop queries out over the other DSL NIC, where they are lost. I have tested and confirmed this.

    Look, even a $20 consumer grade physical stand-alone router can route traffic based on the port (e.g., send all incoming requests on port 3389 for Remote Desktop to 10.0.0.14). Linux can also do this. I don't hold it against Windows that it can't, because I recognize that a multihomed workstation is a fairly obscure configuration. But that's the networking issue. As I've said many times here: THIS HAS NOTHING TO DO WITH ROUTING BY IP#, so it's not a problem that can be solved by adjusting the routing table in Windows. I am very familiar with how to adjust the routing table, so insulting me about not knowing how to do that is not helpful. It's just that the ROUTING TABLE HAS NOTHING TO DO WITH THIS ISSUE, because the incoming IP#s are variable, so there is nothing to route.

    If there were a way to do it by port (3389) or by binding the application to a particular NIC, that would do it. That's how we would do it in Linux. That appears not to be possible in Windows. If that's the case, I wish you would just say that, instead of telling me that I'm too stupid do it.

    All of which brings me back to my original question, which I'd still like to understand, even though I already have a work-around -- is there a way to trigger a Task Scheduler event on a local login/unlock event, but not on a remote login/unlock event?


    Colin


    Wednesday, January 25, 2017 7:17 PM
  • How in the world do you bind an application to a port in Linux.  In Windows we can set the port for RDS very easily but that does not help with the routing table in any way.  If you change the port for RDS all connections to RDS will be lost.  The same is true in Linux by the way.


    \_(ツ)_/

    Wednesday, January 25, 2017 7:46 PM
  • In Linux, you could do it via NAT, directed by port #, just like a consumer-grade router. As far as I know, that's not an option internally within Windows 10. And again, I'm not suggesting it should be -- this is traditionally more of a server function than a workstation function, so understandable it can't be done in Windows 10.

    But it should would be nice if there were a way to simply select: all traffic on port 3389 use NIC1, all traffic on port 80 use this NIC2, etc.

    It would also be nice if there were a way to do it by application: all traffic for Skype use NIC1, all traffic for Remote Desktop Service use NIC2, all traffic for Putty use NIC3, all traffic for Slack use NIC2, etc.


    Colin

    Wednesday, January 25, 2017 8:09 PM
  • You can do the same thing in Windows.  Search for Windows NAT to find documentation.


    \_(ツ)_/

    Wednesday, January 25, 2017 8:27 PM
  • You can do the same thing in Windows.  Search for Windows NAT to find documentation.

    Looks like this is limited to Windows Server (at least by the link that appears when searching Windows NAT -- https://technet.microsoft.com/en-us/library/dd469812(v=WS.11).aspx), which is exactly what I had said above. If this capability has been added to non-server versions of Windows, specifically Windows 10, please let me know. I don't see any hits on that when searching Bing.

    That said, I've further enhanced my work-around by resolving the multi-homing approach such that the system now properly responds to traffic over the incoming NIC (so RDS request comes in on T1, responses go back out over T1, even though DSL is the lower (higher priority) Metric).


    Colin


    Thursday, March 09, 2017 4:11 PM
  • http://www.wikihow.com/Enable-IP-Routing

    This has zero to do with the question and is back to routing based on IP #.

    Colin

    Thursday, March 09, 2017 4:12 PM