I personally say leave the project without it until we find a good solution, preventing user for changing pic wont be good, if we couldn't find a good solution we wait until next Windows version maybe when Microsoft fix something they fix this also for us, I hope lol And for sure thanks mxman2k
I am trying another method that should be simple and effective. User's will then be able to change pic if they wish without the need for reg fix (workaround). Testing in vmware...fingers are crossed.
That didnt work either but I found out why....those pics are in another location as well...all of them. Now to see if I can edit that locked down folder. Wish me luck. Update: Well my other method didnt work. I change images in hidden locked down location and replaced them...all of them even guest images. Went into registry and pointed to user account pictures and nothing changes period. I really think this guest image is in a file like the login background use to be. We only have two options of the reg entry forcing it for all users if left default in oobe.cmd file or do it manually after activation in windows settings.
..\Optional\win10 - optional\ei.cfg\ei.cfg - add [win10].txt first line should be edited : 'Win8.1.iso' should be replaced with "Win10.iso" maybe in next version
Noted but not a priority compared to functionality. Teamviewed with BALTAGY last night and spent many hrs testing Win10 Anniversary. Found some interesting glitches as far as what kms can do to system. Found a possible way to make settings stick. Just editing registry doesnt do it. Some settings revert back after restart. Win10 Anniversary seems to cache info into a file somewhere. Seems M$ made it where you have to user their settings, not registry. Like I said, very interesting.
The user pic and login background pic "can" but too many variables to mention at this point. Still investigating and taking notes. Win10 Anniversary seems to have a cache of some sort and if you don't use windows settings manually, they don't tend to stick. Is this done on purpose or a glitch is still unknown. I know everyone is curious but I could write a book on what changes we have found. Seems the more we research, the more variables we find. I took a break today just to clear my head. Been working on this day and night for a few days now and got burnt. At this point no options other then what is already included. KMS does do something different in settings that cause some settting's not to hold until you manually change personalization settings in order to save (cache) the info. Like I said, interesting.
ok I wish you good luck, I know you find it important to make the oem brand shows itself in every place on the windows, but for me the desktop background is far enaugh, the default user pic from windows is very fine for me to stay as it is, maybe the login bg is a bit different I mean it's good to have it oem branded but it's just not that important, manual changing is a good way out, that's my view.
This anniversary version has quite a lot of changes, some may be for the better, however a few seem to be done just for changes sake, as mentioned - are some a glitch or done on purpose to take away the users ability to customise the OS to their liking ? As some people have found out certain tweaks via the registry and group policy no longer work because they have been removed from the OS or are just ignored. What was once easy to accomplish is now a lot harder or may not even be possible anymore. Helping with this project has gave me more insight into the inner workings of the Windows OS in general, more so the registry. For instance when you change the User pic there are a LOT of changes that happen within the registry. However those entries are only part of the equation.
Exactly. Update: Seems logging off saves the login background pic and user pic. Need more testing to make sure. Will do more later today once I get back in town. Have a good day everyone. Keep the faith. I wonder if I can sue M$ for baldness, failing eye sight and migraines? lmao!
Just wondering, anyone utilizing this for the MDT/WDS deployments? I'm trying to figure out exactly at which step should I do what so the OEM Branding can be applied automatically to the machines. I already have a procedure to detect the branding of the machines which can trigger applying this but just not sure where and what type of switches do I need. Any ideas or suggestions? Also I just noticed the oobe.cmd has been completely re-written from the old version. My question is if it detects no manufacturing ID, i.e. a homebrew box, no further action will be taken? Or like the old oobe.cmd it applies a generic profile?
The old project was abandoned and I re-wrote everything over the last year. There is no support for that version of the old project. Your more then welcome to try the new one. Most files are internal not within the oobe.cmd anymore. Read posts in this thread to research its progress.
Thanks! I've been reading the oobe.cmd command but what I like to know is... what's the behavior of the current project if it detects no OEM info?
In that case it uses the brand of the motherboard and brands windows with the background pics and oem info of that brand in "system".
Awesome. Thank you! May I make a suggestion for the future. Rather than using a generic or board's branding, can the project simply not change anything at all?
If the project cannot find any DMI branded motherboard from the 100+ makes it checks for then you will get the standard default windows theme. But if you have a SLIC for windows vista/7 then i think it will use the SLIC's name to brand the OS instead. The_Guardian can correct me if i am wrong about the using SLIC part if no DMI present. DMI = Desktop Management Interface , a small part of the bios that most board makers use to put information about the board, who made it, serial numbers etc. ie ASUS , ACER, DELL Inc..... SLIC = Software LICence for Vista/7 and some servers only. Allows for pre-activation of the OS. Windows 8.x/10+ no longer uses SLIC for activation and the project will just check for DMI information - if none, default windows theme will be applied. These new OS's use MSDM tables for activation but that is not used for OEM branding. The project however will use the MSDM information to attempt activation if present. Any theme can be 'forced' regardless of DMI/Board make, see Readme files for more information on its use.
@stevedusa, if you delete the OEMs.zip file no branding will take place, only Vista/7 or Win8.x/10 activation will be attempted. No theme or logos etc will be applied.
Thanks! What I am trying to do is utilizing the project among the MDT deployment in our environment with Lenovo & HP machines running Windows 7 Pro downgrade rights from 10 Pros. We also have some custom built rigs in-house which uses our own MAK for activation. My goal is to at the end of each MDT deployment as part of the MDT workflow, the project will assist me to brand, apply cert and key to the machines that have the SLIC in the board for offline OEM_SLP. While the non-SLIC in-house builds will be untouched. While I know the branded systems with SLIC will be taken care off, I'm not sure what the behavior would be if the target machine is just a generic build. In the previous project I often find the maker of the motherboard was applied where no SLIC was applied to the BIOS. I am not sure about the new project thus why I am asking. Thanks again! I can try to play with MDT to do a WMI query and figure out if the project is needed or not at the end of the deployment.