Have you rebooted? I've seen the two out of sync, usually just after manually activating, when the system info page just doesn't update.. Code: cscript slmgr.vbs /dli ... is the only authoritative answer...
There are a copious amount of methods involving the wimgapi.dll. Of course you can combine the methods; however the problem there lies with ensuring each sub-method invocation is assigned to the proper namespace, as they all do not. Most work within the Interop namespace. It also depends on what you want to do. You can use it to return and parse internal XML data, and apply new data: Code: using System; namespace WIMXMLInterop { using System.Runtime.InteropServices; using System.Management; using System.Runtime.CompilerServices; using System.ComponentModel; public class WIMFile { internal XMLDocument m_xmlInfo; internal List<WIMFile> m_imageList; public string WIMImageName { get { return XmlInfo.XMLPathSelectElement("/IMAGE/NAME").Value; { } public string WIMImageDescription { get { return XmlInfo.XMLMLPathSelectElement("/IMAGE/DESCRIPTION").Value; } } public string WIMImageDisplayName { get { return XmlInfo.XMLPathSelectElement("/IMAGE/DISPLAYNAME").Value; } } public string ImageDisplayDescription { get { return XmlInfo.XMLPathSelectElement("/IMAGE/DISPLAYDESCRIPTION").Value; } } public int WIMIndex { get { return XmlInfo.Element().Attribute("INDEX").Value; } } public string WIMImageEditionId { get { return XmlInfo.XMLPathSelectElement("/IMAGE/WINDOWS/EDITIONID").Value; } } public string WIMImageFlags { get { return XmlInfo.XMLPathSelectElement("/IMAGE/FLAGS").Value; } } public string WIMImageProductType { get { return XmlInfo.XMLPathSelectElement("/IMAGE/WINDOWS/PRODUCTTYPE").Value; } } public Version WIMImageVersion { get { major = int.Parse(XmlInfo.XMLPathSelectElement("/IMAGE/WINDOWS/VERSION/MAJOR").Value); minor = int.Parse(XmlInfo.XMLPathSelectElement("/IMAGE/WINDOWS/VERSION/MINOR").Value); build = int.Parse(XmlInfo.XMLPathSelectElement("/IMAGE/WINDOWS/VERSION/BUILD").Value); revision = int.Parse(XmlInfo.XMLPathSelectElement("/IMAGE/WINDOWS/VERSION/SPBUILD").Value); return (new Version(major, minor, build, revision)); } } } } I mean there's more to it than that snippit. I did not add any error control or error values which would be disastrous. You also have to write a method to open the WIM, and close it when finished, which are simple. You'll also want a call handler to relay WIM messages on errors and successful processes, while also declaring legacy values. You can further expand the actual capture/expansion of the WIM, the mounting/dismounting of the WIM, the compression, architecture, languages, etc. All of which you can also set values to. As I said, you can do pretty much anything with a WIM that's well beyond the scope of 99.9% of programs. Then just take your code, and use PowerShell to wrap the code using Add-Type. Then you can create an advanced function that can pipe data to and from the methods string variables. So for example you write that wrapper, and then you can simply use the function to pass new data through the method and to the image using the system's proper namespace for what you're doing.
Using PowerShell wrappers with C# .NET Framework code is how I do most of my imaging of both WIM files and VHD(x) drives, aside from very simple functions. I've always ascribed more to doing things without the use of secondary tools people create and supply but that's also mostly because PowerShell affords the ability to do such things as use other code-styles like C#, Java, C++, etc. and then wrap them in a function and very easily pass information to them using a simple command. You can also use them on other namespaces - like the Local Security Authority namespace - to grant system-level privileges and access rights either locally or remotely by adjusting access token privileges. It's ideal because there's no requirement of having a silly "Bin" folder with SetACL.exe, DISM, wimlib.exe, etc. in order to do what you want. On the other end of the sword, you must be very careful if you're using these types of functions because they can immediately render your system inoperable. All modules and cmdlets I write and submit to PowerShellGet and the official Microsoft repository always states this warning, and also why I invest possibly more error-checking in both the method code and the wrapper function code than required.
An example of one of my functions using wimgapi.dll and a wrapper: Spoiler Code: PS C:\Windows\system32> Get-WIMXML -WimFile "C:\Users\Deployment\WIN_10_PRO_WORKSTATION_16299.15\sources\install.wim" -Index 1 -All -PassThru VERBOSE: Accessing WIM. Handle : WIMXMLInterop.NativeMethods+WIMFileHandle ImageIndex : 1 ImageName : Windows 10 Home ImageEditionId : Core ImageFlags : <null value> ImageProductType : WinNT ImageInstallationType : Client ImageDescription : Windows 10 Home /EA ImageSize : 16158449810 ImageArchitecture : AMD64 ImageDefaultLanguage : en-US ImageVersion : 10.0.16299.15 ImageDisplayName : <null value> ImageDisplayDescription : <null value> Code: PS C:\Windows\system32>$XMLInfo = Get-WIMXML -WimFile "C:\Users\Deployment\WIN_10_PRO_WORKSTATION_16299.15\sources\install.wim" -Index 1 -PassThru PS C:\Windows\system32>$XMLInfo | Set-WIMXML -ImageName "Windows 10 Pro for Workstations" -EditionId "ProfessionalWorkstation" -Flags "ProfessionalWorkstation" -ImageDescription "Windows 10 Pro for Workstations" -PassThru -Force VERBOSE: XML data was successfully changed returning [0] errors. Handle : WIMXMLInterop.NativeMethods+WIMFileHandle ImageIndex : 1 ImageName : Windows 10 Pro for Workstations ImageEditionId : ProfessionalWorkstation ImageFlags : ProfessionalWorkstation ImageProductType : WinNT ImageInstallationType : Client ImageDescription : Windows 10 Pro for Workstations ImageSize : 15527439838 ImageArchitecture : AMD64 ImageDefaultLanguage : en-US ImageVersion : 10.0.16299.15 ImageDisplayName : <null value> ImageDisplayDescription : <null value>
Latest IP 17063 The current 1709 updates can't be installed on 16299.15 pro-ws, so it will stay on build 16299.15.
Hi guys, one more question. Updated the PC to 17074 yesterday... In the registry: - The EditionID is "ProfessionalWorkstation"; - CompositionEditionID is "Enterprise"; - Product Name is "Windows 10 Enterprise Insider Preview". But winver and system properties all say "Pro for Workstations", as does the desktop watermark. So, am I correct to assume that Pro for Workstations is based on Enterprise? (But like a cut-down version?)
Question, did you convert a Home index to Pro-WS or did you do a license switch? Because 17074 is only releases as Home and Pro (+N) by MSFT. This is on a Home>Pro-WS offline converted install: Code: [OSINF] ======================= [OSINF] Version {WMIC} : Microsoft Windows 10 Pro for Workstations Insider Preview x64 [OSINF] Edition {Registry} : ProfessionalWorkstation [OSINF] Edition {WMIC} : ProfessionalWorkstation [OSINF] Edition {CBS} : Professional [OSINF] Build Information : 17074.1000.amd64fre.rs_prerelease.180106-2256 [OSINF] Architecture : 64 Bit [OSINF] Update Build Revision : 1000 [OSINF] Edition Language/Code : en-US / 1033 {409h} [OSINF] Locale : en-US [OSINF] Language Name Value : ENU [OSINF] ======================= Info provided by the MRP project.