none
DA - startup scripts not running RRS feed

  • Question

  • We've configured a UAG Direct Access array and other computer GPO settings are being applied to our Windows 7 test client successfully, however a test .bat set as a startup script under Windows Settings -> Scripts -> Startup will not run.  No error or indication that the client ever attempts to run the script.  gpresult /v indicates the script has never been executed.

    From the client, I am able to navigate to the sysvol policy folder, locate and execute the script successfully.  I've tried setting the Logon -> Always wait for the network at computer startup and logon to Enabled and tested with both hard wired and wireless without success.

    Is anyone successfully running startup scripts w/ DA?  Any suggestions would be much appreciated.

    Thanks in advance!


    • Edited by ChrisC7 Friday, June 1, 2012 2:13 PM
    Friday, June 1, 2012 4:13 AM

All replies

  • Can you access the UNC path where the login script is located from the DA server itself?

    MrShannon | Concurrency Blogs | UAG SP1 DirectAccess Guide | RDS in Server 2012 Guides


    • Edited by MrShannon Thursday, June 7, 2012 11:04 AM typo
    Thursday, June 7, 2012 11:04 AM
  • Was there a solution to this? We also have the same problem. Being able to use startup scripts would be very useful for us as we cannot manage-out DA clients with SCCM because we are not native ipv6.

    I am pretty sure it is due to Direct Access not connecting soon enough to allow computer startup scripts to run because when the user logs in it can still take a few minutes for direct access to connect. Quite often when our client win8 tablets logon there seems to be a delay in wireless network. When we click on the wireless network icon, it doesn't bring up the list of wireless networks to connect to, instead nothing happens. After waiting about 10 minutes this will eventually work and then Direct Access will connect.

    We are pretty sure it is not the server because its status is all green and other clients are connected at the time. The problems seem client related and random.

    Anybody got any ideas how to troubleshoot the DA2012 connection process and what can cause delays?

    We have already disabled the ipv6 transition technologies that are not in use i.e. (6to4,teredo and isatap) We only use iphttps as per URL below.

    http://directaccess.richardhicks.com/2013/08/27/disabling-unused-ipv6-transition-technologies-for-directaccess-clients/

    Thanks

    Monday, September 23, 2013 9:37 AM
  • If your tablets are not turning up the wireless NIC for that long following boot, that sounds like a bigger issue that needs to be addressed at the OS level. DirectAccess can connect even while the computer is sitting at the login screen, the infrastructure tunnel at least. As long as you have your DCs where this script is sitting as part of the Management Servers list (all DCs are added to this list by default), then I would expect that this script should be able to launch, again unless there is something wrong with the machines themselves that they are not turning on the NIC until later in the boot process.

    Rich and I are good friends, but it's not everyone's recommendation to disable all of these. If you have good reasons not to use them, then of course. But in general Teredo is faster than IP-HTTPS and in my opinion shouldn't be disabled.

    Also, you can make use of manage-out in your network without native IPv6, by making use of ISATAP. Do not follow the test lab guides that are out there telling you to create a blanket "ISATAP" DNS record, that will cause more problems than it solves. But there are ways to create selective ISATAP environments which can allow you to specify only the systems you want with outward reachability to have ISATAP connections. Jason Jones has a great guide to this online: http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html, and there is also a chapter regarding ISATAP and the different things you can do with it in this book (self serving, I know, but it does contain all of the information you would need): http://www.packtpub.com/microsoft-directaccess-best-practices-and-troubleshooting/book

    Tuesday, October 1, 2013 1:13 PM