Upgrade Win 8.1 to Windows R2 (cont.)

Upgrade Win 8.1 to Windows R2 (cont.)

Hkey_local_machine\software\microsoft\windows\currentversion\component Based servicing\
Packagedetect
Packageindex
Packages

Microsoft-windows-foundation-package
Microsoft-windows-servercore-package

1. There are two items in the package inspection, respectively:
Microsoft-windows-servercore-package
Microsoft-windows-foundation-package
There are related package names in each of them.
Description: The first one is retrieved through Get-windowsfeature, and the latter one is retrieved by Get-windowsoptionalfeature.
On the server is primarily the first, on the workstation is mainly the second, and on the workstation will not have the first.
That's right, because it's not necessary.

2. In the package index:
There is only one record:
To the server, is microsoft-windows-servercore-package;
On the workstation, is microsoft-windows-foundation-package.
is an index, nothing too much content.

3, in the system of the package index:
Similarly, there is only one record:
To the server, is microsoft-windows-servercore-package;
On the workstation, is microsoft-windows-foundation-package.

4, in the product of the package index:
have their own version name.

5. There is a microsoft-windows-common-foundation-package in the package:
Its owner is: microsoft-windows-servercore-package

6, in the package is clearly to have: microsoft-windows-servercore-package
Its owner is: microsoft-windows-serverdatacenteredition
This is the value of the product AH.

7, now there is a question, in the end is where to confirm the server, or workstation, that is, the value of the Microsoft-windows-foundation-package in the package is:
Microsoft-windows-serverdatacenteredition, or
Microsoft-windows-professionaledition.
Is that the right place to be sure?
Then, backtrack up.

Processing:
For 1:
Because on the server, workstations are required, directly import can.

reg import "C:\CVT\register\Package-Server\p01-Microsoft-Windows-Foundation-Package.reg"reg import "C:\CVT\register\Package-Server\P01-Microsoft-Windows-ServerCore-Package.reg"

The previous one can not be imported, however, the package on the server may be more than the workstation, so it is also imported.

Importing is not easy, either.
There is no edit permission on the package detection, even for the SYSTEM account. Also, there is a problem where you can edit permissions in Registry Editor, but you cannot edit them by Set-acl.
Use. "C:\SysinternalsSuite\psexec.exe" –%-i-s-D regedit starts Registry Editor.
To the SYSTEM to edit the permissions, that is, full control.
Not only to the root of the packet detection authorization, but also to two sub-key authorization: Microsoft-windows-foundation-package, Microsoft-windows-servercore-package.
Use. "C:\SysinternalsSuite\psexec.exe" –%-i-s-D powershell_ise start PowerShell, then execute the above command.

For 2:
is the operation in the package index. The
should delete the Microsoft-windows-servercore-package first and then import the Microsoft-windows-foundation-package.
Again, it is the relevant authorization:
The root and Microsoft-windows-foundation-package subkeys of the package index.

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~0.0.0.0" /freg import "C:\CVT\register\Package-Server\P02-Microsoft-Windows-ServerCore-Package.reg"

For 3:
with 2 treatment.
The root and System subkeys of the package index to authorize.
As if the permission has been inherited, therefore, not authorized also can. But make sure it's not bad.

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\System" /f reg import "C:\CVT\register\Package-Server\p03-System.reg"

For 4:
with 3 treatment.

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\Product" /f reg import "C:\CVT\register\Package-Server\p04-Product.reg"

For 5:
Deal with ibid.
The root and microsoft-windows-common-foundation of the package to be authorized.

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Microsoft-Windows-Common-Foundation-Package~31bf3856ad364e35~amd64~~6.3.9600.16384" /f reg import "C:\CVT\register\Package-Server\p05-Microsoft-Windows-Common-Foundation-Package.reg"

For 6:
Deal with ibid.

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.3.9600.16384" /f reg import "C:\CVT\register\Package-Server\p06-Microsoft-Windows-ServerCore-Package.reg"

Finally, don't forget to change the package index and the package's SYSTEM permissions to read-only.

Reboot the system to verify correctness.
Dism/online/get-features

The system cannot find the file specified.
DISM log files can be found on C:\Windows\Logs\DISM\dism.log
Then find it.
It was actually found in the C:\Windows\Logs\DISM\CBS.log.
C:\windows\servicing\packages\microsoft-windows-servercore-package~31bf3856ad364e35~amd64~~6.3.9600.16384.mum
But this is not a file, but a set of packages. Because we have changed the registry only, but in fact, the file is not homogeneous.
Test the file Installation server again:

"Microsoft-Windows-FileServer-Package~31bf3856ad364e35~amd64~~6.3.9600.16384" ·| % { "E:\temp\$_.mum" } `| % { dism /online /add-package /packagepath:"$_" }

OK.
However, the time is too long, it seems to be running the repair work.

Now, you can fix it.
Release the Install.wm file first.

dism /mount-image /imageFile:D:\Sources\install.wim /index:4 /mountDir:e:\mount /readonly /optimizedism /online /cleanup-image /restoreHealth /Source:E:\mount\Windows /LimitAccess

Upgrade Win 8.1 to Windows R2 (cont.)