I believe it all started with the statement, 16299.xxx Pro-WS won't take updates,,,,, Correction, it was my reply about you being sure you have use for pro-ws...
As said before, you can't get updates on WS but there is a trick that allows to get updates work on WS, as soon as i get the trick from @xinso, i will give it to you.
I will try to slim down my current .DLL file with a handful of the methods and then write a simple group of function wrappers to use them. I will upload them to my GitHub when I have some time to do it. You will have to be careful with some of them, though.
does this has something to do with what we've discussed here since a while ago cause i didn't understand a word from all what you said what are you trying to accomplish ?
I was able to switch from Pro to ProWS and now I've got ProWS activated with HWID for my computer. So now, next dumb question. If I wanted to do a clean install of ProWS . . . what's the best way?
From what I understand here going from Pro to ProWS does not give you the full PFW build. You have to start with Home first.
As just said, you will have to download Home then convert it to WS using WES @s1ave77 which WS version is installed on your machine ?
I do not recall what we discussed "a while ago." I have nothing to accomplish. I was just informing the forum ninny that being gleeful in ignorance is a symptom of Alzheimer's. Next to that, I just make small changes to the Home-to-PfW automated conversion executable and post it for people to use.
I just want to mention that if you link your digital activation to your MS account, then if you decide to install your ProWS in a VM, or on another machine, you just press the troubleshoot button when it doesn't activate, and you will be good to go. I have done this, and it works. It saves a lot of time.
I do not know if any of you have tried this, but I did start from 16278 with the retail ProWS key inserted. Created the GenuineTicket, formatted, installed 16299 Pro in sysprep mode, inserted a key (it digitally activated,) sysprepped (generalized,) captured image, created ISO. Now I have an ISO of 16299 which installs DIGITALLY ACTIVATED even on a machine which has never seen or heard of ProWS. Just a side mention, it was a converted Pro image, so...
@sultan.of.swing i contacted @xinso and he sent me the trick to make updates to work on WS RS3, here it is : Step 1. Use NSudo etc. to run regedit command. Step 2. Export "Component Based Servicing" to a reg file, e.g. 1.reg. Step 3. Edit 1.reg with notepad. Step 4. Search and replace all ProfessionalWorkstationEdition with ProfessionalEdition. Step 5. Save 1.reg. Step 6. Import 1.reg back. (Don't delete the original "Component Based Servicing", because we are ADDING ProfessionalEdition.) All credit goes to @xinso
Yes, I posted that I would trim my main library down to something reasonable for most users, and write a few wrappers for various tasks. Spoiler Code: $ErrorMessage = $_.Exception.Message $RootPath = (Get-Location).Path Push-Location ([System.IO.Path]::GetFullPath((Resolve-Path $RootPath).Path)) $AccessImage = "$RootPath\Bin\AccessImage.dll" If (Test-Path -Path $AccessImage -PathType Leaf) { [void][Reflection.Assembly]::LoadFrom($AccessImage) $WIMFile = [WIM.Interop.WimFile]::New($WIM) $IndexList = [System.Collections.ArrayList]@() $SaveFile = "$HOME\Desktop\WIM_MetaData.xml" } Else { Throw "Unable to locate the required DLL assembly." } Return $WimFile.Images $ImageEdition = $WIMFile.Images[0 .. 9].Flags $ImageInfo = $WIMFile[$ImageEdition] $ImageVersion = $ImageInfo.Version $ImageInfo.AccessHandle($Header, $XML) | % | ? { $_.Name.Replace("\s", "") } | ? { $_.Description.Replace() } | ? { $_.DisplayName.Replace() } | ? { $_.DisplayDescription.Replace() } | ? { $_.EditionID.Replace() } | ? { $_.Property[0].Replace() } | ? { $_.Property[1].Replace() } | $ImageInfo.Close() } If ($IndexList.Count -ge "1") { $IndexList.Clear() } If ($WIMFile -ne $null) { $WIMFile.Close() } This Powershell process just requires one to type Get-WimInfo -WIM and it calls the C# methods in my AccessImage.dll to access the protected image file handle using the Security.Interop namespace. If I want to call WIMGapi, I can.. $WIMContainer = [WIMGapi.API.WIMContainer]::New($WIM) + the $WIMContainer[$($Index - 1)].Apply($Destination) method. Which will partition, format and apply a WIM to a VHD(x) or a physical drive while also applying the proper BCDBoot depending on partition type. This all looks complicated because I am taking snippits from some of my cmdlets (they're useless without the DLL, anyways. But here's an example of a simple one that accesses all images in an image without having to mount or even extract the WIM from the ISO... Spoiler Code: Function Get-WimData { Param ( [parameter(Mandatory = $true)] [string]$WIM ) Begin { $ErrorMessage = $_.Exception.Message $RootPath = (Get-Location).Path Push-Location ([System.IO.Path]::GetFullPath((Resolve-Path $RootPath).Path)) $AccessImage = "$RootPath\Bin\AccessImage.dll" If (Test-Path -Path $AccessImage -PathType Leaf) { [void][Reflection.Assembly]::LoadFrom($AccessImage) $WIMFile = [WIM.Interop.WimFile]::New($WIM) } Else { Throw "Unable to locate the required DLL assembly." } } Process { Return $WIMFile.Images } End { If ($WIMFile -ne $null) { $WIMFile.Close() } } }