SOLVED Windows 10 1703 Image with strange issue

  • Hi,

    i am sure this is not a FOG Problem but i like to ask you all.
    I’ve created a Windows 10 1703 like i always do over admin mode, i was using the same scripts i did with 1607, everything is identical.

    Now when i deploy that 1703 Image everything goes fine until i try to start internet explorer or try to register office 365.
    The registration window for office 365 never appears (it’s not a proxy problem) i only see the grey box but it never asks for username and password and when i try to start internet explorer i can see the process in task manager but ie never appears (gui).

    The only user account where the office reg and ie works is the domain admin account, that doesnt work with local accounts or other domain accounts even when i give them admin rights.

    This is kind of strange, reinstalling office 365 doesnt solve this, i think my image is messed up but i have no idea why that happens.

    I wasted a lot of time creating these images over virtual box, and while creating them i dont have a chance to test this because i just work with the local admin account until i trigger sysprep to create the image, only after deploying i can see the problems i mention now.

    Anyone else with such problem with Windows 10 1703?

    Regards X23

  • Moderator

    @chris6862 FWIW: Between image captures I’ve used the FOG post install scripts to “patch” the target image as FOG deploys it to the target machine.

    In our process we rebuild our reference image once a quarter. We have to go through and validate that the reference image works on all 12 models in our fleet before we can release it in fog for deployment. If we discover a gotcha after its been approved and released (as in needing to add something to the unattend.xml file or setupcomplete.cmd) We will have a post install script run to slide in the correction once imaging is done, and before the system reboots into windows setup. I’m not saying that this process will solve your issue here, but it IS a workable option if you need it.

  • @x23piracy

    Excellent! I forgot about the option to use the “setupcomplete.cmd” script. I’ll implement that now as well instead of deleting the files and folders manually after sysprep.

  • @Chris6862 success 🙂

    I’ve added this to my setupcomplete.cmd:

    rd /S /Q "C:\Users\Default\AppData\LocalLow"
    rd /S /Q "C:\users\Default\AppData\Local\Microsoft\Windows\WebCache"
    rd /S /Q "C:\Users\Default\AppData\Local\Microsoft\Windows\INetCache"
    del /F "C:\Users\Default\AppData\Local\Microsoft\Windows\WebCacheLock.dat"

    My whole SetupComplete.cmd looks like the following:

    sc config FOGService start= auto
    net start FOGService
    PowerShell.exe -ExecutionPolicy Bypass -File C:\Support\Tools\TaskBarLayout.ps1
    C:\Support\Tools\Shutup\OOSU10.exe C:\Support\Tools\Shutup\ooshutup10.cfg /quiet
    rd /S /Q "C:\Users\Default\AppData\LocalLow"
    rd /S /Q "C:\users\Default\AppData\Local\Microsoft\Windows\WebCache"
    rd /S /Q "C:\Users\Default\AppData\Local\Microsoft\Windows\INetCache"
    del /F "C:\Users\Default\AppData\Local\Microsoft\Windows\WebCacheLock.dat"
    del /F C:\Windows\System32\Sysprep\unattend.xml
    del /F C:\Windows\Setup\Scripts\SetupComplete.cmd
    del /F c:\windows\system32\sysprep\panther\setupact.log
    del /F c:\windows\system32\sysprep\panther\setuperr.log
    del /F c:\windows\system32\sysprep\panther\ie\setupact.log
    del /F c:\windows\system32\sysprep\panther\ie\setuperr.log
    shutdown -r -t 60 -f

    Regards X23

  • Hi,

    i am currently testing with:

    rd /S /Q "C:\Users\Default\AppData\LocalLow"
    rd /S /Q "C:\users\Default\AppData\Local\Microsoft\Windows\WebCache"
    rd /S /Q "C:\Users\Default\AppData\Local\Microsoft\Windows\INetCache"
    del /F "C:\Users\Default\AppData\Local\Microsoft\Windows\WebCacheLock.dat"

    within SetupComplete.cmd, i am currently capturing, will test deployment when finished.

    Regards X23

  • @Chris6862
    try to delete those files with unlocker and use /quit for sysprep then the machine will not shut down.
    also psexec could also help, with it you can gain system rights and maybe the rights to delete this.
    if this will work with psexec as system then it’s scriptable.


    I tried your method on a problematic computer and it works 😄
    i think it must be enough to delete those files in the administrator account before we sysprep, because only at the moment after deployment the unattend.xml will take effect and afaik the admin profile will be used for the default profile on the newly deployed computer and what will happen in that moment the problematic files & folders will be copied from administrator profile to default profile, so in my mind deleting those before taking a capture of the golden image should solve it.


    Only delete those files in the default profile before trying a new user logon, that was enough and all works, so my theory should be true, i will test it on the next image.

    lets say this files cannot be deleted when logged in as local admin before sysprep (also with tools and tricks), what about creating another local admin account, login as that, open taskmanager and logoff first local admin (auditmode), delete the files and rerun sysprep /auditmode?

    Computer should reboot then and reenter the audit mode, maybe the profile is clean then and we can start regular sysprep. hmmm 🙂

    I created a package for pdq deploy to fix our problematic computers next morning:

    Bild Text


    I took my image deployed it into a vm and take a look howto get quit of that files, and its possible.
    locallow can always be deleted, inetcache is blocked by explorer, just use unlocker or kill explorer.exe process to delete that folder, webcache and the lock.dat file is opened by com surrogate, just kill the process dllhost.exe and delete the folder and the file.

    When i now just reboot, computer gets back to audit mode and the two folders and the file can deleted without any hassle. so if you want to get sure write something like this in your sysprep script:

    taskkill explorer.exe
    delete inetcache folder
    taskkill dllhost.exe
    delete webcache folder
    delete lock.dat file

    But i am not sure if sysprep needs dllhost.exe, lets try…
    …currently capturing, will deploy after that and see if that error is blown away…


    OK that attempt hasn’t worked but i found out what happened.
    When the sysprep process is finished the 2 folders and the lock file has be recreated after sysprep was running.
    So i use /quit for sysprep and have a pause before shutdown -s -t 0 -f then i kill explorer.exe and dllhost.exe and delete the 2 folders and the lock file after that i ack my pause in my sysprep script and machine shuts down…

    I need to try that now, if this is working we can remove pause and script it without interrupt.
    I get back to you…


    hmm doesnt work, even when i delete that shit at the latest moment possible (before a shutdown) that files seem to be created by what ever, i can delete them afterwards but i don’t have a real solution yet. damn!

    Regards X23

  • @x23piracy

    Yes, I have copyprofile in my XML file.

    Yes, I boot up with a WinPE ISO and/or flash drive to capture my image. The link below should help with making one of those ISO files (or flash drives).

    I too would like to delete those files before Windows shuts down however they seem to still be in use. That could be why sysprep does not remove them as it should.

  • @chris6862 if you say no o&o usage, do you have copyprofile in your unattend.xml?
    Today i deployed a system where the error does not accour, no matter who i am logging in internet explorer and office reg is working.

    I don’t understand howto delete those files, if you say sysprep system normally shuts down after that, then you boot some other live system to remove those files or folders from the filesystem? then you take the image?

    If this is the solution i am sure it has todo with copyprofile bit in unattend.xml, maybe there is something going wrong while making a copy of the local admin to default user.

    But i would like to have a way to delete those files and folders without doing that externally with booting another live system after sysprep, there must be a way.

    I will try your solution tomorrow on a computer where we have an exchanged employe, if this user is logged in on his specific system i have the known problems, i will try to delete those files and folders in his profile to find out it the problems are gone after that and get back to you.

    Regards X23

  • @x23piracy

    I cannot believe it but early results are positive! The same Win 10 Pro x64 1703 UEFI image that has been causing me problems appears to be working after I have logged in with my domain account! My Office 2016 apps did not lock up, IE and Edge did not hang, Search is working VERY quickly now, and I have functioning tiles!

    This is basically a summary of the files/folders to delete that were in my previous link to the MS TechNet site. I had to sysprep, reboot into WinPE, and then delete them as some were in use by Windows.


    “C:\users\default user\AppData\Local\Microsoft\Windows\WebCache”
    “C:\Users\default user\AppData\Local\Microsoft\Windows\INetCache”
    “C:\Users\default user\AppData\Local\Microsoft\Windows\WebCacheLock.dat”


    Maybe this will work for you too.


  • @x23piracy

    Dang! I was hoping it was resolved. I’ve rebuilt the image from scratch at least 5 times. I’ve even kept it off the network during the initial build and then immediately tried using my sysprep.xml. Same results.

    I’m not currently a FOG user but do use GHOST. We’re slowly making the move to MDT and SCCM but that’s a little ways off still.

    Yes, I’m using the copyprofile option as I like for the users to have a consistent desktop experience.

    I have used O&O ShutUp a handful of times but never did so on my images.

    I build my images in Virtualbox. I am maintaining a BIOS based image and have created a UEFI one as most of our machines now will support it. My typical steps to build an image with VBox are as follows:

    1.) Set up the VBox VM (4 cores, 4GB, 60GB HDD, bridged LAN - disabled though until setup is complete, no floppy, ISO is VL Windows 10 x64, then save the bare snapshot
    2.) Run through setup of Windows 10
    3.) When Cortana starts, I hit CTRL-SHIFT-F3 to reboot in audit mode
    4.) Save the snapshot
    5.) Add MS VCRedist as well as enable .NET 2.0 and 3.5 via Progs and Features
    6.) Run all MS Updates
    7.) Install apps such as Chrome Enterprise x64, Firefox, Office 365 2016 x86, CCleaner, FileZilla, KLCodec, Acrobat Reader DC, VPN, Screenpresso, 7-Zip, and a few other apps, set custom desktop wallpaper, some desktop icons, and a few taskbar changes
    8.) Shut down and take a snapshot
    9.) I usually sysprep it at this point and then test it out. All is fine until a different user logs in (usually my domain account) which I’m a local administrator on this system.

    I did run across this link below which may be promising. The last several posts toward the end of the page hint on a few more items to clean up that may take care of the issue. I’m officially on vacation as of about 2 hours ago but plan on trying this out ASAP.

    Thanks for the quick reply!

  • @chris6862 said in Windows 10 1703 Image with strange issue:

    Did you come across any more info on this issue?



    unfortunately no but i created a new image only did basic things and the exact thing happens again.
    two ideas, maybe ms is kicking our asses because of missing reimaging rights, or it has todo with copyprofile in unattend.xml or its maybe the usage of o&o shutup.

    Do you use copyprofile in your unattend.xml and or tools that gain privacy like o&o shutup?

    Regards X23

  • I have the exact same problem with 1703.

    Everything works fine until I log in with an account other than the Administrator account (even new accounts that are members of the local admins group). I’ve been building Windows images for many years and always seem to hit a wall.

    I am also using a new unattend.xml file and using the “copyprofile=true” option as I did with 1607 and prior builds.

    Did you come across any more info on this issue?


  • @george1421 said in Windows 10 1703 Image with strange issue:

    @x23piracy Must have been Tom’s magic pixies that he packed into FOG 1.4.2

    I don’t think so 😉 Today i deployed a mix of different machines and the strange shit is back.
    The case is the first user i log on (domain user) has a working office registration and a starting internet explorer, but each other user i logon to that computer has the issue again.

    What the hell could this be?

    Every new user will be created from the default user, i always use copy profile in unattended.xml so what should cause an issue like that with the problems i talk about only with every user that logs in after the initial one? This is so strange…

    Regards X23

  • Moderator

    @x23piracy Must have been Tom’s magic pixies that he packed into FOG 1.4.2

  • I deployed my UEFI Image in the last hours to 4 different UEFI Systems and it was working on all, i don’t know what happened in the last days when it was not working but it seems to be okay now… Strange!

    I maybe should mention that i updated to 1.4.2 from 1.4.1 last night, but i don’t see any relation.

    Regards X23

  • curious, when i deploy my image back to a vm office 365 activation and internet explorer is working fine. What could this be when this will not work on a physical machine? head scratching…

  • Moderator

    @x23piracy said in Windows 10 1703 Image with strange issue:

    i know this, but you simply gain reimage rights with a single purchase of a VL copy

    I guess my point is this. OEM media != to VLK media. If you have a vlk key then you should use the vlk media that may have certain things unlocked where OEM may be different. I have no proof one way or the other.

  • @george1421 i know this, but you simply gain reimage rights with a single purchase of a VL copy. Then you are also allowed to reimage OEM (thats just a rights fact), what i think is that ms knows that a lot of people do reimaging with OEM so maybe they are evil like features to disable lockscreen in pro version (they disabled that with 1607, now with 1703 you can redisable lockscreen)

    Since i do everything exactly with 1703 like with 1607 i think ms is seeding traps here.

    I will figure this out, i create a new image and change nothing, then i run sysprep and i will see if ie is working or not. If so i can add office 365 to see how that performs.

    Some other rumors could be “CopyProfile” in unattend.xml, i read some stuff where people say CopyProfile breaks sysprep:

    Regards X23

  • @Avaryan i dont talk about starting edge in local administrative account. After sysprepping you cannot start iexplore or activate office 365. ie doesnt show up but there is a process in taskmgr, the office activation window is left grey after 2 minutes it states that it cannot connect to the actication servers (thats not an online problem).

    I know that some programs are not startable under local admin account but thats not the issue. FYI you can change this in the registry:

    Did this in the past to make edge default settings.

    But like i said thats not the issue here.

  • Moderator

    @x23piracy said in Windows 10 1703 Image with strange issue:

    I have the feeling MS is working against reimaging of OEM Version

    Just for clarity, it is against the MS EULA to alter OEM media or images. You can (re)deploy OEM images as long as they are not altered in any way from the way MS constructs the OEM image. To say it another way, making adjustments to the image with applications or settings must be done post imaging with some third party tool (like pdq deploy). OEM EULA licenses do now allow you to create a golden image from OEM media, adjust it, and repackage it for redeployment. You need a VLK media and key for that.

    If you have Win10 pro OEM you can purchase a single VLK key for Win10 pro (plus 4 other items to get to the 5 lice count) and deploy Win10 Pro VLK to as many systems as you were originally licensed Win10 Pro OEM. You can not upgrade licenses with this method. If you want to deploy Win10 Ent you must purchase an upgrade license (VLK) for each machine you want to run Win10 Ent on.