Q: Can we use the followings to reconstruct each other? #1. NanoServer, WinVOS, ContainerOSPlus, etc. #2. WinPE, WinRE. #3. Core, Pro, EnterpriseS, etc. A: No.
I know that is possible, but my idea was to manually apply all the updated files from 20348.3932 Server into Client, which I did succeed doing. The only problems were the registry not updating cause we can't use server's registry on client. Without the updated registry things don't work properly (activation, UWP apps and winver doesn't change number). In theory we can: 1) Update Server 20348 and copy the updated files into 20348 client 2) Erase all server-specific packages that aren't used by the client version 3) Figure out what in the registry the update changes and manually apply the changes from Server registry into Client registry (fixing activation and UWP) This would result in clean 20348 updated Client base without Server-packages with working UWP, updated drivers and up-to-date kernel. Look at the image I sent. Everything in that system is running 20348.3932 but on Client LTSC. DISM version is updated, ntoskrnl is updated, explorer.exe is updated, everything is updated except the registry (where the winver build number is stored among other important things that get changes by the update).
Q: If Client 20348 doesn't need Server Packages to work, what happens if we copy all updated files from Server 20348.3932 into Client 20348.1 LTSC, but remove the server-specific packages/editions from the update? A: If it works, and we manage to update the registry by hand of a tool, then we get updated Client 20348.3932 without Server-packages Q: Can we do it? Should we?
It's impossile. Client and Server package structures are totally different, although Server Desktop Experience is based on top of Client EnterpriseS.
gailium(119) repacked Client packages\updates with Server and CU components. But still impossible to be 100% as expected. You can ask gailium(119). Or read users' feedback. e.g. OEMDefaultAssociations. Official is "Edge" for both Client and Server. gailium(119) uses "IE" for Client.
The UBR will never match the 3932 - so the version will always read 20348.1 Although you can mod the UBR in the registry - when you reboot it will always return a value of 1 There is no value in this as no client components are really updated - there are no client updates in the CU , they have to be repacked
What file controls the UBR? When I manually updated the Server from 20348.1 to 20348.3932, the UBR was 20348.1 until I also copied the registry config files from 20348.3932 (System32/CONFIG). Then the UBR was 3932, persistent even after reboots. The registry configs changed the UBR successfully on the Server image. What would prevent us from doing that on client?
3932 client components must match for the UBR to reflect this Refer to this: https://forums.mydigitallife.net/th...s-reconstructions.88605/page-128#post-1886526
Perhaps they think that 20348 is more stable than 19044\26100. BTW, I cannot extract your UtilityVMEdition.7z with old and new 7-zip.
Q: Some leaked Servers, e.g. 10586.0\16299.15, are missing "Administrative Tools" shortcut. What is it? A: e.g. amd64_microsoft-windows-e..er-server-shortcuts_31bf3856ad364e35_10.0.20348.1_none_320397ed98f21162 Administrative Tools It is component in some System Core manifest.
Q: How to determine whether or not your Construction\Reconstruction is correct? A: With official images, compare 1. C:\Windows\servicing\Packages. 100% identical. 2. Features. 100% identical. 3. FoDs. 100% identical. 4. Apps\Store 100% identical or, at least, you have to learn to integrate what you want.
Q: Is it possible to convert 19044.1415 CMGE_V2022-L.1345 into 19041.1 en-US or zh-CN? This is more difficult than regular Reconstruction. Three aspects: 1. Cross-Edition. e.g. from Core to EnterpriseG. Or from itself to itself. 2. Cross-Language. e.g. from en-GB to es-MX. Or from itself to itself. 3. Cross-Build. e.g. from 19044.1415 to 19041.1288. Or from itself to itself. ---> Cross-Edition + Cross-Language + Cross-Build ---> The highest level of Reconstruction. Don't forget: There is winre.wim. Unless you don't need it.