Jump to content
DeployCentral

GuyE

Members
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About GuyE

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi Ort, Logs attached for an HP 840 G5 called "T25SA". Cheers, Guy T25SA.Logs.zip
  2. 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
  3. 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.
  4. 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
  5. 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
×