GuyE

Hi Glen, The middle task that copies the file to C:\Platform was just a test I added in to see if I could get anything to run in FirstLogon. I chose the Platform folder to avoid possible Windows permissions issues. It doesn’t run - no file is copied. The task has no significance to the workflow though. The 3rd task is the important one, but it also doesn’t run. There is another script run earlier as a PostImage task, from the same answer file, that copies several files from the SmartDeploy server to C:\Windows\Setup ready for the FirstLogon task, including sd_firstlogon_bas.cmd. I can see in the deployed image later on that they’re all there ready to go. I just cant seem to get the 3rd task to execute.

Hi, I've recently updated MDT from 8450 to 8456, SmartDeploy from 3040 to 3060 and built a Windows 10 1909 image from scratch in same way as I've done previously with 1803. The SmartDeploy answer file specifies a PostImage script that copies various files to the deployed image for further configuration. This works. The answer file also specifies a FirstLogon script that runs a StartMenu/Taskbar modification script and a computer naming/domain join script. The FirstLogon script doesn't seem to run now though. The answer file and scripts are all ones I've used successfully before. I've triple-checked for typos and syntax errors. I tried modifying the answer file and including a simple FirstLogon file copy as a test, but the file wasn't copied. This is the relevant part of the answer file including the test copy in the middle task: <tasks> <task> <phase>POSTIMAGE</phase> <command>cmd.exe /c Z:\configfiles\sd_postimage_bas.cmd</command> </task> <task> <phase>FIRSTLOGON</phase> <command>cmd.exe /c copy C:\windows\setup\sd_firstlogon_bas.cmd C:\Platform\testcopy.cmd</command> </task> <task> <phase>FIRSTLOGON</phase> <command>cmd.exe /c C:\windows\setup\sd_firstlogon_bas.cmd</command> </task> </tasks> This is the sd_firstlogon_bas.cmd script called in the 3rd task above: @echo off REM SmartDeploy FirstLogon - BAS cmd.exe /c C:\windows\setup\starttaskbar_import_bas.cmd cmd.exe /c C:\windows\setup\computernamedomainjoin.cmd Previously the image would deploy and the first logon was as the local Administrator with manual password input. The FirstLogon script ran during this logon and the desktop came up with the computername/domain join script paused waiting for input. Not now. Stumped. Any help appreciated. Thanks.

Hi Ort, Logs attached for an HP 840 G5 called "T25SA". Cheers, Guy T25SA.Logs.zip

Hi, After quite a lot of work I've managed to develop a stable 1803 build & deployment process with MDT & SmartDeploy that removes about half of the provisioned Windows apps, sets up a customized Start & Taskbar layout, and uses copyprofile to successfully set up the default user profile. The only remaining problem is the time it takes to log on as the local Administrator for the first time, once sysprep completes. It takes about 15 minutes before the desktop appears and my FirstLogon script runs (initiating a PC rename and domain join script). This is on 4 separate hardware platforms so far. It also happened with 1709 (I gave up on 1709 in frustration due to sysprep always breaking the Windows apps). It's only this one logon. Subsequent local Administrator or domain logons only take 10-20 seconds even with a new user creating a new profile. Is SmartDeploy doing stuff during this first logon and should it take 15 minutes? If not how can I diagnose what's holding things up? Thanks, Guy

Hi, I'm running 2.0.3000 and having trouble completing platform pack downloads. After initiating the download I see the platform pack appear in the SmartDeploy\PlatformPacks folder with a .download suffix. The file size grows then stops. The .download suffix is never removed and the platform pack doesn't appear in the SmartDeploy interface's list. I can manually remove the .download suffix then open the .ppk in Platform Manager. The contents file look normal. Cheers, Guy Update: Although it doesn't appear in the interface's Platform Packs list after renaming the file, it does appear in the list presented during a media build. That's all I need to keep going.

Hi Jeff, The reason I'm running sysprep before capture is to copy the local Administrator's profile to the default user per this post in your forum. Copyprofile doesn't seem to be an option in the Deploy Wizard. I've created the Win10 master image in a HyperV VM with MDT. On first boot it launches into audit mode, I log on as the local Administrator and then customize. Once finished I run sysprep /generalize /reboot /oobe /unattend:c:\windows\panther\unattend10.xml. This answer file was made in WSIM and includes copyprofile and a handful of other settings to autoanswer in the oobe phase (e.g. locale, language etc) after the reboot and specialize phase. My understanding is that because copyprofile runs in the specialize phase you have to allow a reboot in order for it to run. Oobe runs after that and you end up at the login screen. I shut down at this point (to avoid creating a local Administrator profile) and then capture with SmartDeploy. Reading around, the trend seems to be away from default user customizations in master images. With WaaS and the need to create new masters every 6 months these customizations are too manual and time consuming. The advice seems to be to automate as much as possible in MDT then control settings at the other end with group policy. Cheers, Guy

Hi, I'm building a new Windows 10 deployment workflow and was wondering if you could provide some information on what goes on with sysprep unattend files during deployment of the master wim image to the target clients. I understand that some of the settings in the SmartDeploy.xml file are somehow injected into this process, but I'm unsure how Windows is handling the various unattend.xml files created and how SmartDeploy interacts with them. I've read about answer file search order and that C:\Windows\Panther is used to keep a cached master copy of unattend.xml that is used by the sysprep phases. I don't know how this is created and modified though, or at what points. In testing I started with my own unattend.xml file in C:\Windows\Panther\Unattend\ and no others anywhere in C:\Windows. I used this to generalize the master image before capture. I broke out of a subsequent deployment to a target during the postimage phase with cmd /k, and discovered a new unattend.xml file in C:\Windows\Panther (the cached master?) and another in C:\Windows\System32\Panther, neither of which look like mine - they look more like the one used by MDT when creating the master image. Were these created and left over from the generalize sysprep? The settings in my unattend.xml seem to have been disregarded during the deployment, critically an autologon to support PC renaming and domain join (due to computer naming being deprecated in Windows 10 sysprep oobe). Our old Windows 7 workflow has two copies of our unattend.xml copied as postimage tasks to C:\Windows\Panther and C:\Windows\System32\Sysprep\Panther. I picked this up from a post somewhere several years ago to solve a problem and it worked, but I've never really understood why. Perhaps something similar is required for Windows 10? Can you shed some light on how this all works please. Thanks, Guy