Litetouch deployment of Win7 stalls due to logon security notice GPO

Answered Litetouch deployment of Win7 stalls due to logon security notice GPO

  • Wednesday, June 27, 2012 4:55 PM
     
     

    We recently implemented a security notice at logon.  Since then I've found that when running my litetouch deployment, the deployment is paused when the system reboots for some reason after domain join, because the security notice appears and waits for someone to click OK.  As soon as I click OK, the deployment script continues as usual. 

    Short of moving the computer accounts out of the OU affected by this GPO, is there anyway to avoid this notice grinding my deployments to a halt until someone comes by to click ok?

All Replies

  • Wednesday, June 27, 2012 6:23 PM
     
     

    Nope.

    A couple of options off the top of my head.

    1 - Don't join the domain until the end of the task sequence

    2 - Join a quarantine OU and move the machine to the correct OU when complete.

  • Wednesday, June 27, 2012 10:04 PM
     
     
    My concern with those would be that I do need most of the other GPO's to still apply during the imaging process, such as policies regarding bitlocker encryption etc.  And moving a computer out of it's OU and back every time we want to re-image it sounds like a real hassle.  I'll have to see if I can move the domain join a little later, but still early enough to apply GPO's to the other important steps, and come out with a happy medium.
  • Thursday, June 28, 2012 4:33 AM
     
     Answered

    The staging OU is the most practical, but here are a few others:

    http://www.microtom.net/deployment/temporary-disable-legal-notice-dialog-during-windows-7-deployment/

    http://deployment.xtremeconsulting.com/2009/12/08/new-for-mdt-2010-ztidomainjoin-wsf/

    http://www.deployvista.com/Default.aspx?tabid=78&EntryID=147

    http://social.technet.microsoft.com/Forums/en-US/mdt/thread/3d89c773-e615-4d5e-8f63-ecdcd6dad795

    and the one that I use...

    http://blogs.msdn.com/b/alex_semi/archive/2009/08/28/avoiding-legan-notice-that-breaks-mdt-autologon.aspx


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    • Marked As Answer by Gai-jin Thursday, June 28, 2012 3:30 PM
    •  
  • Thursday, June 28, 2012 3:19 PM
     
     

    http://www.microtom.net/deployment/temporary-disable-legal-notice-dialog-during-windows-7-deployment/

    http://social.technet.microsoft.com/Forums/en-US/mdt/thread/3d89c773-e615-4d5e-8f63-ecdcd6dad795

    Thanks.  These two look like they'll do what I need, disabling the legal notice while still joining the domain at the same time, in the correct OU.  The post from Brano Lukic in that 2nd thread looks like the simplest, so I may try that first.  I'm just wondering if it will work, since there are reboots in the task sequence after the domain join.  Will the Computer policies GPOs be re-applied after reboot, even if only local admin logs in?  Or will they not re-apply until a domain user logs on for the first time?

    Thanks!

    • Edited by Gai-jin Thursday, June 28, 2012 3:30 PM
    •  
  • Thursday, June 28, 2012 3:52 PM
     
     
    I actually haven't tried either of those, but as of GPOs, I added a command line task sequence to force GPO Updates after it joins the domain.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

  • Tuesday, July 10, 2012 9:14 AM
     
     

    Hi Frank,

    Please can you share (if you don't mind) the command line TS to force GPO Updates after joining domain?

    Thanks.

  • Tuesday, July 10, 2012 11:38 AM
     
     

    Hi Frank,

    Please can you share (if you don't mind) the command line TS to force GPO Updates after joining domain?

    Thanks.

    the one that I can think of is using a batch file with the content

    echo n| gpupdate /Force

  • Tuesday, July 10, 2012 11:54 AM
     
     

    That's right, gpupdate.exe /force.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

  • Saturday, August 04, 2012 6:08 AM
     
     
    Hi,
         I've been able to join to the domain as normal, but when I started getting the security screen (to accept before logging on), I tried the step above that you said you use. It does bypass the security logon but now it only joins to the workgroup and no longer joins to the domain. Any ideas?
  • Saturday, August 04, 2012 1:51 PM
     
     
    Which step are you using to bypass the disclaimer?

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

  • Sunday, August 05, 2012 12:53 PM
     
     

    I am was using the step you use, modifying the ZTIDOMAINJOIN.

    I've since changed it all back (the ZTI changes), but left the CSEnableLegalNotice in place, very near the end...
    and moved Recover From Domain back up to just before Tattoo...and I don't get the legal screen anymore.
    I have LanDesk as our Antivirus agent and remote client; the only thing I have trouble with is being able to
    see the machine on the domain to remote into it. It shows offline or not connected to the domain. In order to
    install LanDesk, the machine MUST be on the domain first, so I've done that. It may be that the Apply Network
    Settings isn't taking...I have to look at that...its not applying the DNS/WINS.

  • Tuesday, August 07, 2012 10:28 AM
     
     

    Our solution was to only add the AD Group that applies policy as an application at the end. This let us do a few things:

    1. We could still initially login as local admin, and run the application script under alternate credentials (a domain admin service acct).

    2. It would apply policy after logging into the PC, and the reboot at the end of the deployment would set it for the next startup.

    Granted, it is dirty, and there is probably a cleaner way of doing this, but this currently works for us....

    In application list:

    %ComSpec% /C "\\DeploymentServer\DeploymentShare$\AppScripts\DesktopPolicy.bat" && Exit /B 0

    In DesktopPolicy.bat:

    net use T: "\\AppServer\d$" password /user:Domain\domainadmin
    wscript "T:\AApplication Script\Individual Scripts\DesktopJoinToController.vbs"
    net use T: /delete

    In DesktopJoinToController.vbs:

    Set objNetwork = CreateObject("Wscript.Network")
    strcomputername = ucase((objnetwork.computername))
    Const ADS_PROPERTY_APPEND = 3
    Set objGroup = GetObject _
        ("LDAP://CN=Security Group,OU=Groups,OU=Department,DC=Domain,DC=Forest,DC=Local")
    objGroup.PutEx ADS_PROPERTY_APPEND, _
        "member", Array("cn="&strcomputername&",OU=Desktops,OU=Department,DC=Domain,DC=Forest,DC=Local")
    objGroup.SetInfo


    With that vbs, the first LDAP line is for your AD group that you want the PC added to. The 2nd LDAP line is the location of the PC in AD.
    • Edited by VulturEMaN Tuesday, August 07, 2012 10:34 AM
    •