at least the VRam (when working is accurate) Just sorting QT v90, i will get the damn thing right once and for all
QT v90.0 Uploaded. Should now mention zero bytes and a message why. Code: ================================================[ Graphics Information ]================================================ Adapter 1 Info : Microsoft Basic Display Adapter [Active] | VRam: 0 Bytes Adapter 1 Other Data : Resolution: 1024x768 | Bpp: 32 | Driver Date: 2006-06-21 | Driver Vers: 10.0.18272.1000 Adapter 1 Other Data : Zero Bytes VRam detected, may mean default Windows display driver in use. Video Ram {VRam} Notes : Amount shown may also include any assigned shared system memory. If for some reason WMIC cannot detect the GPU Adapter 1 name then the graphics section will be missing - or blank.
Right time to get MRP 109 BC1 ready for testing.... Then Baselined. Then hopefully i can take a small break as going code blind sorting errors out
You would think m$ would assign at least 32MB to the default graphics adapter. Don't they love to totally <beep> things up.
Regularly and intended it seems, why making it easy for some tweakers (vast minority) . I just noiticed their naming change for en-gb ISOs to en-uk . Good @Mujja noticed it, i wouldn't have checked for that .
MRP 109 is now at Baseline. A few last minute alignment issues has been sorted. Will be released later today, (this evening GMT).
MRP v109.0 has been uploaded, 2nd post download link, password and hashes updated. Spoiler: MRPv109 Summary + Updated Insider/Preview build detection and information about Rings etc. Due to changes in the newer Preview Builds the MRP may not always detect it being an Insider OS, hopefully this will be sorted once m$ have settled on a new standard Insider/Preview build identifier. + Added new option: Disable 'Enhanced' Clipboard for W10 Builds RS5+. You can revert this option later via the EnableClipboardHistory.cmd script within '\Optional\Misc_ExtraScripts\Windows10_Kernels' folder if you wish. Note as this option uses Policy registry entries the section within the Settings App may be greyed out. + If for some reason the OS has locked the 'aero.theme' file then MRP will use the backup $OEM$.theme system to allow themeing to work. This also allows for the theme to be consistent if SFC.exe reverts the theme to a default one. Rare it happens but it seems Microsoft are intent on making the OS use their own default theme regardless of the user's wishes. The routine will be updated as required if any further changes are detected. + Various code tweaks and cleanups done. Added extra error checking in some areas. A few spelling mistakes may be in the change log file within the archive.
Question / heads up! Is anyone here using V1809? A sysprepped version? For the past days I've been tearing my hair off my head in a really dumb issue I've been having. Today I finally solved it! Im using a reference image in Deployment toolkit, version is 1809 and MDT 8456. After deploying this image to a VM or my laptop i would simply use sysprep.exe /OOBE /reboot. It would work just fine and reboot but I'd recieve a "OOBE EULA" error where it supposedly should've displayed the EULA.. For copying your project to proper folder before sysprep i had a script running in the task sequence, this would give me the error After removing the command line in the task sequence it finally worked. The script is applied fine when installing/deploying the OS What I havent tried yet: Using xcopy to see if its the script messing up the files Adding $OEM$ to an ISO or wim manually and using Windows Deployment Services. EDIT: Does not work when copying files manually to %windir%\Setup\Scripts EDIT2: Im thinking it may be some mrpconfig stuff
If installing the OS/Edition of choice then entering sysprep before capturing the OS to an image with the project files in the scripts folder, the problem will be that MRP runs through to completion before the Audit mode's 'desktop' has appeared and will auto delete the scripts folder during the next 'boot' stage of deployment or maybe sysprep while still auditing. Which is probably why your own script is being deleted on the next 'boot' of the image during deployment. The only way to have MRP run as intended would be to have the system sysprep'd without the project used, then have the MRP in the scripts folder when deploying - like a normal ISO/USB install would be or to mount the newly made install.wim and adding the project files to the Scripts folder so that the project will run and then delete the scripts folder like it does under a normal installation. At one time I had the project 'pause' if Audit mode was detected but it caused a few other technical problems, ie the switch rate of the 3 stages was so fast it could cause malfunctions, not just in MRP but the Audit mode process too which was not desired. Now the project will detect Audit mode was used and mention that it was 'detected' in the project's log but does not pause.
It worked very well in 1803, which is why Im confused. MDT (MS Deployment Toolkit) is run from a server, it deploys an OS and performs changes in Audit mode and then syspreps to capture (if capture is chosen, to create a reference image) The reference does not have MRP. The script is removed when the deployment is over and the sharefolder is unmapped from the target computer, in this case a VM. i then redeploy that reference to a VM or computer, to hand over to a friend or whatever, before sysprep I either copy manually (like yesterday) or automatically using the script I found, it searches through the $OEM$ folder of the deployment share, same file structure as MRP, the standard stuff. I, in no way, is blaming MRP, I love the tool!
Hmm then it must be the sneaky changes m$ have been adding, the theme side on latest Insider builds have been locked to that lite theme, but have managed to make the changes in the registry so that any required theme set within MRP is used, it does require a reboot once the desktop has appeared but that is what normally is needed anyway to set any options used. More so for Servers if using any theme.