Our reboot step after the task sequence seems to take at least 5 minutes before it actually reboots in Windows 10, the Windows 8.1 build takes about 45 seconds.
Thanks, Jeff Jerousek From: [email protected] [mailto:[email protected]] On Behalf Of Stephen Owen Sent: Thursday, January 14, 2016 9:42 AM To: [email protected] Subject: Re: [MDT-OSD] RE: Setting Autologin at end of OSD Build Hi guys, Sorry to resurrect an ancient thread, but how did you end up resolving this? Got the same issue here for a customer of mine Thanks! On Fri, Sep 4, 2015 at 3:00 PM, Daniel Ratliff <[email protected]<mailto:[email protected]>> wrote: Yeah it should, I agree. I haven’t done it in a while, but when I had trouble in the past I just set a scheduled task to run 5 minutes later or something like that. Daniel Ratliff From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Marable, Mike Sent: Friday, September 04, 2015 2:34 PM To: '[email protected]<mailto:[email protected]>' Subject: [MDT-OSD] RE: Setting Autologin at end of OSD Build That’s a good question. I thought SMSTSPostaction was supposed to execute once the task sequence had completed and cleaned up after itself. At least that was my belief. If this test doesn’t work my next step will be to execute a batch file as the last step. That batch file spawns another script (maybe my PoSh script) which sleeps for maybe 10 seconds to let the TS close out and clean up. Then it sets the auto login, maybe triggers a GPUpdate and reboots. Mike From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Daniel Ratliff Sent: Friday, September 4, 2015 2:21 PM To: [email protected]<mailto:[email protected]> Subject: [MDT-OSD] RE: Setting Autologin at end of OSD Build Is the task sequence still running when that post action runs? If the machine is still in Provisioning mode that might be why GP wont apply. Daniel Ratliff From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Marable, Mike Sent: Friday, September 04, 2015 2:04 PM To: [email protected]<mailto:[email protected]> Subject: [MDT-OSD] Setting Autologin at end of OSD Build I’m running into a bit of a problem configuring auto login on a Windows 10 OSD build. What I have is a PowerShell script assigned to run using the SMSTSPostaction variable. The script configured the autologin keys and then reboots the system. What I’m having problem with is that when the system reboots it comes up with GPOs still being blocked just like they are during the task sequence. If I reboot the system again (a second time) then it applies the GPOs. This only happens on a Windows 10 build. I use the same task sequence to build a Windows 7 system and it works fine. The reboot from the script brings the system up with GPO processing. I would like to get GPOs enforced immediately upon completion of the build. I’m trying a build now with Invoke-GPUpdate added to the PowerShell script. It runs that, then applies the autologin keys and then runs Restart-Computer. Hopefully that might work. Has anyone else run into this or are in a similar situation and have it working smoothly? Mike Marable Microsoft Systems Engineer Lead Enterprise Device Engineering and Management MCPS, MCITP, MCTS, MCSA, MCSE, MS [Profile<http://www.mycertprofile.com/Profile/5319166625>] [Blog<http://thesystemsmonkey.wordpress.com/>] ---------------------------------------------------- "The difficult we do at once. The impossible takes a little longer." -US Army Corps of Engineers "It is better to have less thunder in the mouth and more lightning in the hand." -Apache Proverb I will rise when I have fallen. "Unless you try to do something beyond what you have already mastered, you will never grow." -Ralph Waldo Emerson ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. ********************************************************** Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
