SESSIONNAME Variable no longer present during login script processing. RRS feed

  • General discussion

  • For decades I have used the line "if /i "%sessionname:~0,8%"=="ICA-tcp#" EXIT" to prevent login scripts from running on Citrix servers. I have also used other variations of "if /i "%sessionname:~0,8%"=="RDP-tcp#" and if /i "%sessionname"=="console" in scripts. Recently these scripts started misbehaving and I discovered that the SESSIONNAME variable is no longer available when logon scripts run. The SESSIONNAME variable does not seem to get defined until afterwards. Once my desktop appears I can open a DOS prompt and see the SESSIONNAME variable. I suspect a patch released last month, 6/2016 resulted in this changed behavior. BTW Windows XP systems do not have this issue.

    I have already figured out a workaround for this but I am curious if anyone else has seen this and if they know which patch caused it.

    FYI. The workaround is to add this line to the beginning of my scripts. "

    if "%SESSIONNAME%"=="" for /F "tokens=2" %%f in ('query user ^| find /i "%USERNAME%"') do set SESSIONNAME=%%f


    Thursday, July 14, 2016 5:17 AM

All replies

  • Hi Frank,

    how about deploying Logon scripts via group policy, don't link them to your terminal server's OU-Tree and use Loopback processing.

    That way it won't even start processing the script to begin with.
    Also makes the whole thing more manageable, since you don't have to read the script to learn whom it applies to.


    There's no place like

    Thursday, July 14, 2016 7:37 AM
  • These are drive mapping and other settings that are user / department unique that are tied to the users AD profiles. We do use GPO scripts for more globally applied settings.
    Thursday, July 14, 2016 12:24 PM
  • Hm, I see. While I'd argue that department-specific configurations should go into GPO, by-user selective settings may well be best handled like this.

    I'd assume a blocking files on the target system might work well, as it will always function and is not restricted to the kind of machine or connection you are using to access it.

    I'm kind of surprised about the changes Microsoft did in recent times (though the change to the context in which GPOs are retrieved had the greatest impact so far). Can't say I know why and how this specific change happened though ...


    There's no place like

    Thursday, July 14, 2016 12:40 PM