Tripredacus

Getting somewhere, maybe.... This could have been a perfect storm, a situation where something else was changed besides the WinPE version and caused this issue to appear... The SK1200KP with a RAID 1 and spindle disks is the same in both WinPE versions. And then these results using 14393 on a PRIME B450M-A, since the NUC would not boot on that PE version. As seen here, it is the same as 17763! But certainly NVMes were definately being detected as disk 0... how could that be? Well I am testing with local PEs not production PEs. They are mostly the same, but obviously there is something different. Production PEs have always detected NVMe as Disk 0 like all other disk types, and it was only the "local" PE that would detect NVMe as Disk 1... UNTIL 17763 came out, and then either build detected an NVMe as Disk 1. Here is the NVMe on the B450M-A using the production PE v14393 where it is detected as Disk 0: I can't put the OCs into the production PE, so I can't run the wmic command. I can do this comparison between B450M-A with NVMe using Production 14393 (detected as disk 0) AMD-RAID Bottom Device Advanced Micro Devices, Inc. rcbottom SCSIAdapter PCI\VEN_144D&DEV_A802&SUBSYS_A801144D&REV_01\4&2074c63f&0&000E @System32\drivers\pci.sys,#65536;PCI bus %1, device %2, function %3;(8,0,0) 0x00000000 0x00000000 No Yes 5/14/2020 3:28:57 AM 5/14/2020 3:28:54 AM AMD-RAID Bottom Device 9.2.0.87 oem17.inf rcbottom_Inst.NT 9/21/2018 5/14/2020 3:28:53 AM AMD-RAID Controller [storport] Advanced Micro Devices, Inc. rcraid SCSIAdapter {54cb850d-a731-8590-0628-1992592bd448}\rcbottom\5&d1e0a6&0&131071 0x00000000 0x00000000 No Yes 5/14/2020 3:28:56 AM 5/14/2020 3:28:54 AM AMD-RAID Controller [storport] 9.2.0.87 oem19.inf rcraid_Inst 9/21/2018 5/14/2020 3:28:54 AM AMD-RAID Samsung SSD 950 SCSI Disk Device (Standard disk drives) disk DiskDrive SCSI\Disk&Ven_AMD-RAID&Prod_Samsung_SSD_950\6&10c8e623&0&080200 Bus Number 8, Target Id 2, LUN 0 0x00000060 0x00000000 No Yes 5/14/2020 3:28:57 AM 5/14/2020 3:28:57 AM N:\ Disk drive 10.0.14393.0 disk.inf disk_install.NT 6/21/2006 5/14/2020 3:28:56 AM and same but with local PE 14393 (detected as disk 1) AMD-RAID Bottom Device Advanced Micro Devices, Inc. rcbottom SCSIAdapter PCI\VEN_144D&DEV_A802&SUBSYS_A801144D&REV_01\4&2074c63f&0&000E @System32\drivers\pci.sys,#65536;PCI bus %1, device %2, function %3;(8,0,0) 0x00000000 0x00000000 No Yes 5/14/2020 3:39:23 AM 5/14/2020 3:39:22 AM AMD-RAID Bottom Device 9.2.0.127 oem11.inf rcbottom_Inst.NT 7/5/2019 5/14/2020 3:39:21 AM AMD-RAID Controller [storport] Advanced Micro Devices, Inc. rcraid SCSIAdapter {54cb850d-a731-8590-0628-1992592bd448}\rcbottom\5&d1e0a6&0&131071 0x00000000 0x00000000 No Yes 5/14/2020 3:39:22 AM 5/14/2020 3:39:22 AM AMD-RAID Controller [storport] 9.2.0.127 oem13.inf rcraid_Inst 7/5/2019 5/14/2020 3:39:22 AM AMD-RAID Samsung SSD 950 SCSI Disk Device (Standard disk drives) disk DiskDrive SCSI\Disk&Ven_AMD-RAID&Prod_Samsung_SSD_950\6&10c8e623&0&080200 Bus Number 8, Target Id 2, LUN 0 0x00000060 0x00000000 No Yes 5/14/2020 3:39:26 AM 5/14/2020 3:39:26 AM D:\ Disk drive 10.0.14393.0 disk.inf disk_install.NT 6/21/2006 5/14/2020 3:39:26 AM Any M.2 shows up as a RAID device on AMD boards, since it does not use the SATA controller, rather to be able to detect the disk you set NVME mode to RAID. A comparison of just the driver info (from Nirsoft's Devmanview) shows that two different RAID driver versions are being used. I could see that as being related to this issue happening on an AMD board, but not the Intel based boards. I will have to do some tests with those AMD drivers removed and see if it makes any difference.

The license requirements are for System Builders, integrators or OEMs. It related directly to fulfillment scenarios, aka selling the OS and a computer. That edition is designed not for retail sale, but for sale along with a full computer system. The OS has to be installed onto the hard drive, the COA put onto the case and the Pack itself included as an accessory. It is basically a restriction from selling the kit on its own in the Retail Channel. For an end user, you can use it to install to a computer without a problem. You do not need to use the OPK. For Windows 7, only OEMs were able to use the OPK and for System Builders and end users they could use the WAIK. All of that was replaced by the ADK. For those wondering, there is no mistique about the OPK, the only difference between it and the WAIK for Windows 7 (from what I can tell) is one .chm file that has additional license requirements for OEMs and System Builders. With the ADK, MS had made one kit for everyone and now the OEM specific documentation is paywalled and separate from the kit. A situation you may find is that storage or USB drivers are missing from the DVD. You would need to use the WAIK or ADK to add USB drivers into the image and then rebuild the install CD. But this process is not different than with other versions of Windows 7. If you do run into this USB issue, if your computer has PS2 ports you can get around it (instead of rebulding the DVD) by using PS2 Keyboard/mouse for the initial setup, install the USB drivers and then switch to your USB devices.

Welcome to the MSFN!

It is in IoT as well and has some issues. The UWF does not support full disk or volume. For example, it will not work properly if you are using single read-only disk. Look in the requirements for the feature, Pro is not there.

The Rules and Donate links in your signature are broken.

This is answered earlier in the thread. https://msfn.org/board/topic/181489-cpi-error-messages-other/?tab=comments#comment-1181520

You'd have to test if that works. I always run things through cmd.

Done

What I get from here: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/hh825129(v=win.10)?redirectedfrom=MSDN Is that the enable/disable of optional packages inside of the Foundation Package must be done with an /apply-unattend, and that branch should be in Offline Servicing and not just Servicing branch. The image must then be installed using Setup, using your XML that does not have the offlineservicing object in it. Onedrive can be uninstalled, I usually do it with first run commands. Here is the cmd: c:\windows\syswow64\OneDriveSetup.exe /Uninstall

Another test, using RAID1 with 2 SATA disks. So with this, a RAID volume is detected the same as the NVMe, as being BusType 8. However it is Disk 0 and has a location path. So unfortunately, I cannot find a way to programmatically tell the difference NVMe and a RAID volume besides what seems to be checking location path. And I have a feeling that wouldn't be a valid method anyways because that field should have data in it. Other observations: the RAID vdisk doesn't have a valid Disk ID.

Here is an example of an XML that will hide those <settings pass="oobeSystem"> <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <InputLocale>040c:0000040c</InputLocale> <SystemLocale>fr-FR</SystemLocale> <UILanguage>fr-FR</UILanguage> <UserLocale>fr-FR</UserLocale> </component> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <OOBE> <HideEULAPage>true</HideEULAPage> <NetworkLocation>Other</NetworkLocation> <ProtectYourPC>3</ProtectYourPC> <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE> </OOBE> </component> </settings> The input locale is for France. Ref: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/default-input-locales-for-windows-language-packs

Corrected title, it is cpi not cip. This line item is only used by WSIM to automatically load a catalog when loading an answer file to be used against the mounted image. It is ignored by Setup and Sysprep. Nearly all of my answer files still retain the Vista Business CLG notation from when I first made an answer file with WSIM way back then. <cpi:offlineImage cpi:source="catalog:d:/sources/install_windows vista business.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" /> The only reason to remove the offlineImage object is if you need to load your XML into WSIM and the XML was initially built using a different source image or catalog set. If the Catalog path is invalid or correct, WSIM will show an error. See if your XML validates against a stock install.wim without the things you added into it. If you see a fail during Setup, you first have to determine which phase it is. The two phases have existed in Windows Setup for many years, including XP. There is the phase where everything is done from the install media or from the WinPE RAMdisk, and the second phase are things being done from the install disk. Knowing which phase the error occurs is important because you then know where to find the log files. If on the disk phase, the log files will be in c:\windows\panther\ and c:\windows\panther\UnattendGC. Both would have a setupact.log. Note that setuperr.log is typically not helpful. WinPE phase log files: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/deployment-troubleshooting-and-log-files Disk phase log files: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-log-files-and-event-logs

If the car was from a cab company, the age of the car wouldn't have anything to do with any computers that the company owns.

Welcome to the MSFN!

Still waiting on 2004 to be released. The information I got was GA is April 2020, so it is supposed to be released today! But probably not.

Dropdown is not a great example to use here, you could do it without javascript before CSS3.

The partition numbers would be correct. I suspect that the OS volume is getting Vol 0 simply because it is mountable, aka it is getting a drive letter. Another observable, although it is not immediately obvious by looking at the output I posted. In the deployment system I manage, a system with a formatted hard disk should get the letter N. This is seen in the SATA SSD M.2 output, where Windows volume is letter N, and the NVME it is letter D. In the expected scenario when booting off USB, an existing volume would get C, USB would get D. Then a script is run to change any C drive to N. This script is an old one and dates back to instances where card readers would be given drive letters even when media wasn't present. So in the NVME example, the USB drive is C, the Windows volume is D, the USB drive is changed to N, but is removed prior to running the diskpart and wmic commands. The expected is that the Windows volume is C, the USB drive is D and the script changes C to N. In any case, it would appear the volume order is not matching partition order. It is something else I can look at when I test on the older WinPE version noted. I also will re-run this test using an onboard RAID configuration using SATA spindle disks to see if there is any way to differentiate an m.2 in "RAID mode" vs an actual RAID array. If anyone knows of any other way to connection type with WMIC, it would be helpful. As I have not tested it yet, but knowing what goes through production, I am quite certain that actual RAID arrays are not being given Disk 1 and instead of Disk 0, as RAID1 are commonplace and I would have heard about those systems not being able to deploy. And I can't go on the presumption that a BusType 11 disk appearing as Disk 1 is an NVME because a RAID array on a controller card may appear the same way, if an onboard SATA, or RAID1/0 or M.2 SSD is detected as Disk 1.

While unknown as to what version this issue started with, the problem is replicated in WinPE v10.0.17763.1 but is not replicated in v10.0.14393.0. After much testing it appears that current WinPE detects an NVMe in an m.2 socket as a different type of disk (as expected) but then gives priority to other interfaces when it comes to disk numbering. The issue has been seen on 5 different boards so far, two different chipset manufacturers and 3 different board manufacturers. Using a fixed driver set, WinPE v10.0.14393.0, booting via USB with a board where the only disk installed is in an M.2 socket, either SATA SSD or NVME, WinPE will give the M.2 device Disk 0 and the USB key Disk 1. Using the same driver set, and WinPE v10.0.17763.1, booting via USB with a board where the M.2 socket has a SATA SSD, the M.2 device is Disk 0 and the USB key is Disk 1. If the device in the M.2 socket is an NVMe, the M.2 Device is Disk 1 and the USB key is Disk 0. That is the problem. I have collected information relating to how the devices are detected on v10.0.17763.1, using a NUC10i3FNK with M.2 SATA and M.2 NVMe. In each scenario the USB key is removed prior to running the diskpart or wmic commands. The NUC10i3FNK is set to AHCI and RAID is not an option. Yet the WinPE will detect the NVMe as BusType 8 aka RAID and have no location path. There is only one M.2 socket in the system and no settings were changed in between testing the SSD vs NVMe except for obviously removing one and installing the other. Normal WinPE is not able to run the WMIC command listed above. It requires WinPE-WMI, WinPE-NetFX, WinPE-Scripting, WinPE-PowerShell and WinPE-StorageWMI WinPE_OCs .cab files, installing the StorageWMI last. WinPE component reference: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/winpe-add-packages--optional-components-reference WMI MSFT\_Disk class: https://docs.microsoft.com/en-us/previous-versions/windows/desktop/stormgmt/msft-disk

The bus mouse returns! From inside the Express BIOS tool from Intel for a NUC10i3. For whatever reason there are tons of "things" listed inside, including processors like RISC and "Hobbit Family", socket types including ZIF, battery composition types (Lithium Polymer, Nickel metal hydride, etc). I had thought that perhaps it was for some compatibility checking, but there is no way a 64bit Windows BIOS flashing program is ever going to be updating a BIOS on a Pentium II.

Windows self-optiziming? Never heard of such a thing. I have always struggled at making sense of this tool at times. I always compare boot time to uptime. If I have a long uptime system, boot time is unimportant. If they are not long uptime systems, then I would compare boot time to disk type. I would never put a modern OS (Vista or newer, but also probably anything if possible) on a 5400rpm disk. For a 7200rpm disk I expect boot times to be maximum 1 minute. For SSD on used OS (not new install) it would be 30 seconds.

We know it is possible because it is something that can be done on PXE with Linux and WDS. You'd need a way to replicate that procedure if not using PXE. How it works in general... the client requests to boot to the server, the server asks for capabilities, the (typically) LAN firmware sends capabilities, then the PXE server passes along the appropriate boot option. For a local based solution, you'd need an initial boot platform that is not firmware dependent, can detect the capabilities of the client and then boot the appropriate EFI image. I would imagine the initial boot would have to be on DOS or Linux, or perhaps even an EFI application or EFI-shell script.

Possibly related to an old issue I had The thread is a mess and a resolution was never posted into there. I swear that a resolution was posted on the forum, but I am having trouble locating it. The issue in that thread was that I could boot in IDE using in-box drivers but not boot into RAID using Intel RAID driver unless I would zero out the MBR on the disk before installing. As for the resolution, for some reason I have this memory of the boot image having 2 indexes and having to inject the drivers into both (usually it is only index 2) before it would deploy. However, I also do not know if I had used my regular method of creating images on finicky hardware: creating a base install on another system. I looked on my deployment server and I ended up only using a single image and it was deployed using imagex to 1 partition. So I think that once the initial install was done, redeploying it wasn't an issue.

LTSC is not optimal for modern gaming hardware, specifically due to the fact that it is so far behind in build numbers. This is a problem for video cards and their drivers, as well as some other situations. I do work with LTSC, where 1809 is the latest build. There are other compatibility issues in general between video cards, software and CPUs with retail Windows builds, and the LTSC SKUs share these problems.

Tons of people not being able to go to a physical school building because their government has closed those venues due to the coronavirus.

Topic split from