Windows 10 1703 Image with strange issue
-
@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.
-
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…
-
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
-
@x23piracy Must have been Tom’s magic pixies that he packed into FOG 1.4.2
-
@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
-
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?
Thanks
Chris -
@chris6862 said in Windows 10 1703 Image with strange issue:
Did you come across any more info on this issue?
Thanks
ChrisHi,
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
-
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!
-
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\Administrator\AppData\Local\Microsoft\Windows\WebCache”
“C:\Users\Administrator\AppData\Local\Microsoft\Windows\INetCache”
“C:\Users\Administrator\AppData\Local\Microsoft\Windows\WebCacheLock.dat”“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”“C:\Users\Default\AppData\LocalLow”
Maybe this will work for you too.
-
@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
-
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
try to delete those files with unlocker and use /quit for sysprep then the machine will not shut down.
https://portableapps.com/apps/utilities/iobit-unlocker-portable
also psexec could also help, with it you can gain system rights and maybe the rights to delete this.
https://blogs.technet.microsoft.com/askds/2008/10/22/getting-a-cmd-prompt-as-system-in-windows-vista-and-windows-server-2008/
if this will work with psexec as system then it’s scriptable.EDIT:
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.EDIT2:
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:
EDIT3:
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 fileBut 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…EDIT4:
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…EDIT5:
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
-
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 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 -fRegards X23
-
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 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.
