I have not touched the script in months so it has to be something m$ is doing to break it. I am waiting to see what m$ does before going any further. Take the complaints to them.
Did you edit anything as far as the included scripts? Is this x64 only or is x86 affected as well? If the info folder is deleted then its M$ stopping branding. Wonder if M$ send a different iso to oems that allows branding? Something is majorly changing. Until all the changes take place there is no sense in looking into this and playing follow the leader crap. Yes, I am getting tired of M$. In fact, looking into a mac lappy to replace M$ crap.
Its x64 updated last week with Simplexes Pack. Could be a coincidence but sometimes my NIC plays up and doenst have a network connection during install, sometimes it does. Wonder if its pulling a update or something that deletes the branding during install? 7 and 8 have been branding and activating fine until I dropped 11-13 into it but it could be a coincidence.... Ill try on my lappy for a couple of installs this week see if I can reproduce it.
In your case its the slipstreaming problem again that Mr.X and others have experienced in the past. If I test with my original iso's I bet it works still for win vista-8.1. Win 10 th2 is a different ball game.
Dude, again I will say it, there has been no changes to the script in many months so it isn't the project but the slipstreaming. Yes, it could be a update that is deleting the info folder and stops the reg entry from being applied. Who knows...too many changes with M$ to be exact. Now you know why I don't slipstream. lol I only use original iso's, period.
Your custom AIO iso is way to big and my internet always fails. I know M$ is going through changes but until the dust settles, we need to wait. I will address all of this in the future but to expect it today, not going to happen. lol
Even if I use regini to "try" and change permission for system to be able to apply the reg key, can the system change its own permission if system is being used? See my problem? This is why you can do all of this from desktop under user acct but not from system anymore. I have tried runonce reg entry and schtask and none will allow the reg key to be applied. Its the SYSTEM that is now limited.
I have a few idea's on how to approach this problem and hopefully will solve those that use slipstreaming as well. Within a few days I should have time to test a few theories I have. Update: I cant lock out the system because the system is in use so we cant lock down the info folder. I will need to edit everything for another location but that isn't a biggie. I need to figure out how to get the reg entry to hold. This is the problem more then the info folder. The info folder can be moved to another location but the reg file I need in that exact location or win10 x64 th2 or any slipstreamed iso will not have the oem theme available. Update2: I cant get the reg entry to take. I am at a loss on this one guys and gals. Seems M$ doesnt want branding to change thus maybe why oem's really dont brand heavily in win10. End users might have to enable the oem theme themselves instead of it auto being enabled when at desktop. I know everyone will complain but if anyone has a better idea, I am up to hear it.
My personal opinion since Microsoft pulled v1511 then last RTM is Build 10240, you should wait until we see what Microsoft doing and let's wait for next iso's, After all your work maybe Microsoft fix all problems and you see the project working again Personally if any of my customers want Win10 i will install Build 10240 until Microsoft release a new official build
What seems strange to me is that the x86 versions work where the x64 version broke in th2. If they changed something in one you would think the other would be done the same. This is why I say M$ broke something. Now with th2 coming slowly in windows update, instead of iso, I wonder if a update is what is causing this problem. Would explain why some slipstreams have similar issues. Info folder being deleted and I bet the reg entry was never entered either. I see a change but not sure what direction to go in. I know I can move the info folder to a stable location (theme will work this way with th2) that will work for all by editing everything from the ground up but if the reg entry doesnt stay applied then no system info. I need a solution to the reg file entry for oem info in system properties. This is the problem. Seems the SYSTEM doesnt allow or cant do some things or its refusing oobe.cmd from access. You can do it from desktop though. It's confusing...one reg file away from a solution. lol I need a beer.
After doing more testing in win10 x64 I have noticed that not only is the info folder being targeted but all reg entries. The reg files run but get deleted. I added query checks to logging to find this out. Right before the desktop pops up, its all deleted. For right now use Alphawaves system brand changer which works from desktop as a workaround until I can figure out a way of bypassing this lock down, if I can.
Is there a way of telling which 'Account' is deleteing the reg entries? You could try something like SetACL to change permissions on the keys to a higher account (like TrustedInstaller?) after theyve been set to try and lock them down? (a complete guess here). If this is the way its going to end up, with Alphas SBC working from the desktop, longterm solution could be a RunOnce CMD that pulls the system info and applies through SBC on login? @The_Guardian - Can't wait to see your MultOEM for MacOS lol If 7/8 werent so good Id be going the fruit route as well!
what is the problem? i have used your project with 64 bits 10586 and my user picture and wallpaper was changed succesfully after setup.
I am not repeating myself on every page, read past posts. Since it wont work on my system config but project works with some, I am not going to be able to provide support since even in vmware my hardware is still tied to the install and the project fails for me with win10. Bottom line, M$ s*cks! Its not a permission issue so to speak but M$ stopping the project. The files and reg entries are being ran and applied but they are being deleted. Here is a hint from M$ themselves, if app is found incompatible, it gets deleted. Isnt that whats happening here for some of us? Now the question is how to determine if a system is compatible or not and add to log file at least? Also you cant lock down the system from removing files and reg entries because it cant lock itself out while the system is running. There is nothing I can do but wait and see what M$ does...in the mean time, I am looking into buying a mac. The main problem with my less then a year old lappy is that the 4th gen cpu isnt supported according to the HP assistant for windows upgrade to windows 10. This is the worse support for an OS I have ever heard of from M$!
i dont think that it is some app compatiblity issue. yours should not be considered an app. isn't it just script to apply some oem settings? with some computers the oobe configuration settings screen where you set some privacy settings comes twice. there is a post about this. i think your script applies settings successfully but then oobe screen comes again and resets everything reletad with oobe. so i think it is really about this bug. you shouldn't mess with your script.