• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 2 replies
  • Subscribers 16 subscribers
  • Views 3043 views
  • Users 0 members are here
Options
Related

Logon timing "Desktop" not working as expected

sauerk
over 3 years ago

We have two classes of users, remote users that connect using a VPN and on-site users that are on the local network at one of our branch offices.

The remote users that use VPN have a challenge if we want to use Desktop Authority to push out programs at login.  The challenge is when they log into their computer, they are not on network yet so we have two icons placed on these users desktop.  1-VPN Login launches the Cisco Anyconnect SSL VPN client where they can log in and get "on network".  the second icon is called 2-Network Login which is a shortcut pointed to \\domain.com\netlogon\slogic.bat.  This runs the script logic logon script and it provides them mapped drives, printers, some registry tweaks, etc...

However, we are seeing that an application launcher event for something like msiexec with the arguments populated with /i "\\domain.com\dfs\applications\program\program.msi" /quiet /qn /norestart with validation logic like if C:\Program Files (x86)\Program Name\programfile.exe does not exist - does not run - ever.  It only runs on computers that are on the network all the time, like one in our 8 or so office locations.

So thinking its because the timing element "LOGON" will never be true because the VPN users are logged on with cached credentials prior to launching the VPN client... we also selected "DESKTOP" timing event, and in the help file it says "Check this box to execute an element when a client logs on to the computer. The element will execute after the logon process completes."

That sounds exactly like what we need.... the element SHOULD execute after the logon process completes, but it doesn't.  The sltrace file just shows this element 79/79 of this case but not the command under it.

What is the best way to get things to run when the slogic.bat file is manually invoked after the machine has already been logged in?  Drive mappings work fine.  I'm seeing a lot of other things in the sltrace.htm log work fine like file, folder, registry permissions, registry tweaks, printers.  What's with application launcher not working as expected?

Parents
  • 0 over 3 years ago

    Hello sauerk,

    Regarding the VPN users, I don't know what version of the KACE Desktop Authority are you running, but there is an option under Global Options | Common Location Options | Network Location Awareness. This Network Location Awareness (NLA) is used to configure NLA within the Desktop Authority Console. NLA. Desktop Authority uses Network Location Awareness to detect when a new network connection becomes available. Once the new connection is detected, the Desktop Authority will be notified and can then determine whether it will execute for the user. If you don't see the Network Location Awareness you will need to upgrade to the latest version 11.1.0.0 in order to be able to use it. 

    Regarding running the logon script manually after the desktop loads, I would like to mention it is possible but not recommended and should not be done.  The first reason why it is not recommended is because Microsoft recommends that if you are going to assign a logon script, then you should set the value in the registry named RunLogonScriptSync which causes the operating system to complete any logon script assigned to the user before the desktop loads.  The second reason is that most of the settings in the logon script alter the registry and if they are not set before the desktop shell loads, then those registry settings will not take effect unless the desktop shell is reloaded or the user logs off and then logs on again.  It is far better to follow Microsoft recommendations and use the mechanisms that they supply to govern logon scripts and to fix the real underlying problem instead of redesigning the basic functionality of core components. 

    My recommendation will be to enable the NLA and if you still having issues with the VPN users, please create a service request in our Support Site to review the issue.

  • 0 over 3 years ago in reply to Jorge.Corrales

    Hi we are on 10.2.0.256.  I'm not sure how an upgrade would even go if theres about 50 to 60 users at home on vpn.  I think upgrades like that would have to be postponed until work from home is no longer "the norm".  If its still possible to upgrade and then when those home users click the second icon to run the login script, the system is smart enough to just upgrade without requiring any admin intervention automatically, then I'd consider it.

    The problem is you cannot run a login script before you are logged into the VPN because the location of the logon scripts \\domain.com\netlogon is not accessable obviously.

    Computers are signed on while in the office on wifi, the profile is built, then they switch to a public wifi and test and train on vpn and soff phone system.  This all happened around march/april.  Then they took the computers home and connected to their home wifi.  Some have returned back to the office so instead of around 90 people at home, we are around 60 people at home, some on a rotating basis.

    So they log in to the computer and its cached credentials.  They open the Cisco Anyconnect VPN client and log in.  They accept a 2FA push to their mobile device to complete the login.  Now after logging in they have a private IP address on our VPN subnet and can access all resources, such as DFS file shares / netlogon.  So to get mapped drives to make it easier they can run the second icon that group policy pushed out to the work from home OU that essentially runs \\domain.com\netlogon\slogic.bat.  The majority of the registry edits and first time setup was already done back in march / april when on site.  So running this now basically has the effect of ensuring those registry settings are enforced and still set what they were, and drives are mapped, printers are set, etc...

    So its really the chicken before the egg scenereo.  If you have to be "logged in" to click the icon to initiate the VPN connection, you are already at the desktop at that point.  AD password changes are handled by the fact that when they are VPN'd in, and GP refreshes on its hourly schedule, they do get pop ups (and we have an email goes out at 14, 7, 3, and 1 day until password expiration).  While VPN connected they can do CTRL+ALT+DEL and choose change password and updated the AD password.  Since they are connected it also updates the cached credentials, so at the end of the day if they shut down (effectively disconnecting the VPN), the new password works the next login, and that new password works in Cisco Anyconnect.

    Next year we are looking to get rid of Cisco ASA's and move to Palo Alto or Fortigate.  Depending on how that VPN client works, the process could change.

Reply
  • 0 over 3 years ago in reply to Jorge.Corrales

    Hi we are on 10.2.0.256.  I'm not sure how an upgrade would even go if theres about 50 to 60 users at home on vpn.  I think upgrades like that would have to be postponed until work from home is no longer "the norm".  If its still possible to upgrade and then when those home users click the second icon to run the login script, the system is smart enough to just upgrade without requiring any admin intervention automatically, then I'd consider it.

    The problem is you cannot run a login script before you are logged into the VPN because the location of the logon scripts \\domain.com\netlogon is not accessable obviously.

    Computers are signed on while in the office on wifi, the profile is built, then they switch to a public wifi and test and train on vpn and soff phone system.  This all happened around march/april.  Then they took the computers home and connected to their home wifi.  Some have returned back to the office so instead of around 90 people at home, we are around 60 people at home, some on a rotating basis.

    So they log in to the computer and its cached credentials.  They open the Cisco Anyconnect VPN client and log in.  They accept a 2FA push to their mobile device to complete the login.  Now after logging in they have a private IP address on our VPN subnet and can access all resources, such as DFS file shares / netlogon.  So to get mapped drives to make it easier they can run the second icon that group policy pushed out to the work from home OU that essentially runs \\domain.com\netlogon\slogic.bat.  The majority of the registry edits and first time setup was already done back in march / april when on site.  So running this now basically has the effect of ensuring those registry settings are enforced and still set what they were, and drives are mapped, printers are set, etc...

    So its really the chicken before the egg scenereo.  If you have to be "logged in" to click the icon to initiate the VPN connection, you are already at the desktop at that point.  AD password changes are handled by the fact that when they are VPN'd in, and GP refreshes on its hourly schedule, they do get pop ups (and we have an email goes out at 14, 7, 3, and 1 day until password expiration).  While VPN connected they can do CTRL+ALT+DEL and choose change password and updated the AD password.  Since they are connected it also updates the cached credentials, so at the end of the day if they shut down (effectively disconnecting the VPN), the new password works the next login, and that new password works in Cisco Anyconnect.

    Next year we are looking to get rid of Cisco ASA's and move to Palo Alto or Fortigate.  Depending on how that VPN client works, the process could change.

Children
No Data