Jason M

I found an acceptable workaround using the legalnoticecaption and legalnoticetext registry keys. The goal is to know exactly when it's safe to remove a laptop or PC from the imaging shelf without needing to check the console, and this does it quite well. This is especially helpful for brand new machines imaged via PXE boot, since it seems the easiest way to tell whether those are done is to keep refreshing the "Installed Software" list until the last application in the answer file you used shows up. What I did was add the following command to the SPECIALIZE phase in the Answer File under Answer File Wizard > Advanced > Tasks. cmd.exe /c reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v legalnoticecaption /t REG_SZ /d "SmartDeploy Imaging" /f && reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v legalnoticetext /t REG_SZ /d "Applications are being installed and configured. This computer will restart when the process is complete." /f Then create a "Run Command" task with the following CMD arguments which removes the Lock Screen notice, add it to the Answer File and move it to the bottom of the "Install Order" list. /c reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v legalnoticecaption /t REG_SZ /f && reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v legalnoticetext /t REG_SZ /f I like to reboot my machines at the end of the imaging process, so I added the above step right before my final reboot task; however, a reboot is not required as these registry changes are immediate. More info on the registry keys used: https://www.addictivetips.com/windows-tips/custom-lock-screen-message-in-windows-10/

Looks like there's a way around this limitation. As long as you're using the same account to domain join each time, you won't need to delete the computer object since the owner of the object stays the same. So if you're using a service account to domain join all your machines, you'll probably be fine. I understand this may not be best practice but it sure is convenient 😁

Thanks, Devon. Is this a Microsoft limitation? I know there are multiple ways to domain-join a computer via command line.

Is there a way to domain join a machine without having to delete the computer object in AD first? All my attempts to do so failed, even when using domain admin credentials. Somehow, SCCM can join machines to the domain over existing just fine, and I even tried using our SCCM credentials with SmartDeploy, no luck.

Confirmed this was the cause in my scenario, as I forgot to include "/c" in yet another "Run Command" task. The fix was to kill all the hung CMD processes running on the client machine.

I have the same question. Is it safe to assume that all Application Packs are run during the FIRSTBOOT phase as mentioned above, regardless of type? (application vs. script).

FYI - I tried sending a message via PowerShell as the first task, hoping that it'd actually pop-up for me to see at the login screen; unfortunately it did not work.

Post-image deployment, is it normal for the login screen to appear before all applications are installed / tasks are completed? If I were to sign in as soon as I see the login screen after an image deployment, majority of the apps would be missing and it'd be another 25 or so minutes before they show up. If I recall correctly, SCCM had, at the very least, pop-up messages indicating that things were still being worked on in the background, so I knew the machine wasn't finished until that message went away. Is this not something SmartDeploy does? Just curious as I've only recently started using it. For me, it's super convenient to know when I can pull a laptop off the imaging shelf without having to look at the console.

I had this same issue when forgot to include the "/c" in the arguments of my last "Run Command" task post-deployment. No matter what I did (reboot console, reboot client, restart services on both ends, power down client and wait, etc.), nothing canceled the "ExecutingTasks" message until I deleted the computer from AD, re-joined it to the domain and rebooted; which probably wasn't even the fix since it's also possible that the task finally timed out.

This is probably related to removing the provisioned appX packages. That's the only thing I did differently when I started seeing the "An app default was reset" notifications. I haven't even applied any custom file associations yet. Still testing..