" You cannot do a gpudate from within a task sequence because the OS is in provisioning mode during task sequence and so will not apply Group Policies while the task sequence is running. That was added to Configmgr a long time ago. "
are you sure about that, it's not blocked anymore and does seem to work (gpupdate /force) in the Windows phase of OSD [image: Inline image 1] On Tue, Feb 6, 2018 at 1:57 AM, Ashutosh Mishra <[email protected]> wrote: > we tried it all in our might but nothing helps. We ended up with having > manual intervention skipping the auto-logon. > > Regards, > Ashu > > On 6 February 2018 at 10:47, elsalvoz <[email protected]> wrote: > >> Have you tried adding a schedule task before the TS is done and run your >> commands that way? Something like make changes to auto logon and reboot the >> system. >> >> >> >> Cesar A. >> >> On Feb 5, 2018 4:10 PM, "Miller, Todd" <[email protected]> wrote: >> >>> The 6 minute countdown is something we put in so that we had time to >>> remote into the registry to check out the autologon registry key from >>> remote regedit. The length of countdown doesn’t matter. The Restart is >>> done by the TSPostAction variable. The computer should sit patiently at the >>> CTRL-ALT-Delete for 6 minutes, reboot and autologon. The original timeout >>> is only 15 seconds – we just extended it so that we could investigate the >>> computer state before the reboot. We can see that some process is clearing >>> the . >>> >>> >>> >>> You cannot do a gpudate from within a task sequence because the OS is in >>> provisioning mode during task sequence and so will not apply Group Policies >>> while the task sequence is running. That was added to Configmgr a long >>> time ago. >>> >>> >>> >>> >>> >>> I am looking for a way to ask the SystemOOBE, when it is finished >>> screwing up the computer to perform a few commands to put the autolgon back >>> in place. Undo the damage it has caused, and kindly reboot the computer – >>> and if possible, to do it without Cortana telling me about it. >>> >>> >>> >>> >>> >>> *From:* [email protected] [mailto:[email protected] >>> orum.com] *On Behalf Of *Lanctot, Charles >>> *Sent:* Monday, February 05, 2018 2:09 PM >>> >>> *To:* [email protected] >>> *Subject:* RE: [External] Re: [MDT-OSD] Autologon not working in 1709 >>> ZTI Task Sequence >>> >>> >>> >>> I think the 6 minute wait on the shutdown might be your problem, the >>> task sequence wont wait 6 minutes if you’re just telling it to “shutdown -r >>> -t 360”, the command will execute successfully and the task sequence will >>> move on. As mentioned before the autologon keys are deleted in the cleanup >>> script (run after the task sequence finishes). A custom exit script may >>> resolve your issue but how about doing it like this: >>> >>> >>> >>> OS Deploy Task Sequence >>> >>> 1. Deploy OS >>> 2. App Installs etc >>> 3. Change autologon keys to use domain account >>> 4. Domain join (if not joined already) >>> 5. Reboot >>> 6. Run Command Line: Cmd.exe /c gpupdate >>> 7. Reboot >>> 8. The end (Runs cleanup and deletes autologon keys) >>> >>> >>> >>> This way you get your domain login with your 2 reboots and a gpupdate to >>> boot. >>> >>> >>> >>> *From:* [email protected] [mailto:[email protected] >>> orum.com <[email protected]>] *On Behalf Of *Miller, Todd >>> *Sent:* Monday, February 05, 2018 1:47 PM >>> *To:* [email protected] >>> *Subject:* RE: [External] Re: [MDT-OSD] Autologon not working in 1709 >>> ZTI Task Sequence >>> >>> >>> >>> >>> >>> I have found a more recent twitter thread that describes my problem >>> pretty exactly, no solutions offered though… >>> >>> >>> >>> https://twitter.com/MyNameIsMurray/status/950200568496119808 >>> >>> >>> >>> It seems SystemOOBE in 1709 is destroying autologon settings. >>> SystemOOBE appears to be suspended during TS, so it runs once the task >>> sequence is complete and ruins *everything*. Need to figure out some >>> method of modifying Unattend.xml to replace the autologon stuff once >>> SystemOOBE is finished wreaking havoc. I hear it is a bad idea to disable >>> SystemOOBE, so need to figure out how to fix things up once it is finished. >>> >>> >>> >>> >>> >>> >>> >>> *From:* [email protected] [mailto:[email protected] >>> orum.com <[email protected]>] *On Behalf Of *D D >>> *Sent:* Monday, February 05, 2018 11:46 AM >>> *To:* [email protected] >>> *Subject:* [External] Re: [MDT-OSD] Autologon not working in 1709 ZTI >>> Task Sequence >>> >>> >>> >>> This is typical, I believe an MDT script deletes this at the end, but I >>> can't recall which one.... likely the cleanup. >>> >>> You might get away with a post action: >>> >>> https://www.petervanderwoude.nl/post/how-to-perform-an-actio >>> n-directly-after-the-task-sequence-is-finished-with-configmgr-2012/ >>> >>> >>> >>> >>> >>> On Mon, Feb 5, 2018 at 12:14 PM, Miller, Todd <[email protected]> >>> wrote: >>> >>> We have a Win 10 1709 ZTI task sequence, that at the end configures the >>> computer to autologon with a domain account. We use this to perform some >>> post installation processes that cannot be included in the task sequence >>> like forcing group policies to apply. Some GPOs only apply on a second >>> reboot so we force these two reboots to happen post TS. >>> >>> >>> >>> This works fine in 1607, but we are having trouble after dropping in the >>> 1709 wim. >>> >>> >>> >>> Michael had this tweet -- https://twitter.com/mniehaus/s >>> tatus/880308506477318146?lang=en – describing this issue – kind of, >>> maybe. >>> >>> >>> >>> I think the issue people were having in 1703 is with MDT LTI processes >>> not loading up as the local admin account to perform software installs and >>> maybe has no relation to ZTI deployments through Configmgr aside from both >>> using the autologon registry. >>> >>> >>> >>> Our problem is with ZTI deployments though configmgr. We are using a >>> script to edit the registry to enable autologon. We are finding that when >>> the task sequence finishes, the autologon registry values have been deleted. >>> >>> >>> >>> We are >>> >>> 1. Editing the registry using a script. >>> 2. Pausing the TS so we can verify the registry – this looks correct >>> all necessary keys are present. >>> 3. Exit the pause. >>> 4. Set the TS exit command to reboot with a 6 minute countdown. >>> >>> >>> >>> Sometime in the six minute countdown, the autologon key is being >>> removed. It feels like this is happening during the new Cortana thing that >>> runs at the end of the task sequence. Something in the reboot process >>> post Task Sequence is clearing out our autoadminlogon keys. The >>> userpassword key is still present but the default user key is empty and the >>> autologoncount key has also been deleted. We are pretty confident this is >>> not a GPO wiping out the registry problem. >>> >>> >>> >>> Is there any technique available that will let us autologon with a >>> domain account at the end of a ZTI task sequence that is deploying 1709? >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> Notice: This UI Health Care e-mail (including attachments) is covered by >>> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is >>> intended only for the use of the individual or entity to which it is >>> addressed, and may contain information that is privileged, confidential, >>> and exempt from disclosure under applicable law. If you are not the >>> intended recipient, any dissemination, distribution or copying of this >>> communication is strictly prohibited. If you have received this >>> communication in error, please notify the sender immediately and delete or >>> destroy all copies of the original message and attachments thereto. Email >>> sent to or from UI Health Care may be retained as required by law or >>> regulation. Thank you. >>> ------------------------------ >>> >>> >>> >>> >>> ------------------------------ >>> >>> Notice: This UI Health Care e-mail (including attachments) is covered by >>> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is >>> intended only for the use of the individual or entity to which it is >>> addressed, and may contain information that is privileged, confidential, >>> and exempt from disclosure under applicable law. If you are not the >>> intended recipient, any dissemination, distribution or copying of this >>> communication is strictly prohibited. If you have received this >>> communication in error, please notify the sender immediately and delete or >>> destroy all copies of the original message and attachments thereto. Email >>> sent to or from UI Health Care may be retained as required by law or >>> regulation. Thank you. >>> ------------------------------ >>> >>> >>> ------------------------------ >>> Notice: This UI Health Care e-mail (including attachments) is covered by >>> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521 and is >>> intended only for the use of the individual or entity to which it is >>> addressed, and may contain information that is privileged, confidential, >>> and exempt from disclosure under applicable law. If you are not the >>> intended recipient, any dissemination, distribution or copying of this >>> communication is strictly prohibited. If you have received this >>> communication in error, please notify the sender immediately and delete or >>> destroy all copies of the original message and attachments thereto. Email >>> sent to or from UI Health Care may be retained as required by law or >>> regulation. Thank you. >>> ------------------------------ >>> >> >
