Announcing Windows 10 Insider Fast Build 16257 PC + 15237 Mobile  

Kari said:

I can't understand this! I've only been able to test this on four UEFI devices, all fail, you got it working in first run! What's wrong on my laptop and tablet (and my neighbor's laptop and desktop, after my tests failing asked them to test, too, both failed).

Anyway, thanks for testing this.

Running great on my ASUS-U46SV on UEFI:

Code:

PS C:\> Set-ExecutionPolicy RemoteSigned -Scope Currentuser

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might 
expose you to the security risks described in the about_Execution_Policies help topic at
https:/go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "N"): y
PS C:\> Install-Script -Name Get-WindowsAutoPilotInfo -Force

NuGet provider is required to continue
PowerShellGet requires NuGet provider version '2.8.5.201' or newer to interact with NuGet-based repositories.
The NuGet provider must be available in 'C:\Program Files\PackageManagement\ProviderAssemblies' or
'C:\Users\Toni\AppData\Local\PackageManagement\ProviderAssemblies'. You can also install the NuGet provider by 
running 'Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force'. Do you want PowerShellGet to
install and import the NuGet provider now?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y

PS C:\> Get-WindowsAutoPilotInfo -OutputFile $env:userprofile\desktop\Test.csv
PS C:\>

No issues!

Kari said:

Thanks Andre!

OK, now I need to find out why it fails on all physical UEFI hardware I've tested. Might it be OEM / Retail related? All devices, mine and neighbour's I've tested have Retail licenses. Secure Boot is ruled out, that I know already.

I am on UEFI x64 on Retail Windows Pro

My Serial# is alphanumeric (capitalized)

@Kari

Would you like me to convert the whole VMImport.exe issue to a full blown Visual Studio project and trace down the permission BUG for connection to the Server/Host Computer?

Maybe this way I can locate which .NET assembly needs some improvements or specific permission modifications to support non-elevated execution of the import tool!?! Or should we just let MS fix this?

It would be a BIG project.:)

slicendice said:

Running great on my ASUS-U46SV on UEFI.

slicendice said:

I am on UEFI x64 on Retail Windows Pro

I was running tests all night, I have now also ruled out OEM / Retail in addition to Secure Boot as culprit for these occasional fails. This is driving me nuts, I need to either find the reason or find a place where I can get good psychiatric care :)

slicendice said:

Would you like me to convert the whole VMImport.exe issue to a full blown Visual Studio project and trace down the permission BUG for connection to the Server/Host Computer?

I've already run some debugging on VS.



I just abandoned that project temporarily when I found this from my point of view even more interesting AutoPilot self deployment issue.

Kari said:

I've already run some debugging on VS.



I just abandoned that project temporarily when I found this from my point of view even more interesting AutoPilot self deployment issue.

Yeah, I saw that post. I tracked down the issue to being a permission error to connect to local computer. This means we can not connect to the Hyper-V Server on local host without elevated privileges. Maybe there is another workaround for this, by modifying some permissions somewhere...

That AutoPilot issue is very interesting. I have no issues with it at all. Re-ran the command multiple times, and everything works great every time. :)

Kari said:

I was running tests all night, I have now also ruled out OEM / Retail in addition to Secure Boot as culprit for these occasional fails. This is driving me nuts, I need to either find the reason or find a place where I can get good psychiatric care :)

Hahhah, find a good doctor...

..kidding... when I have time, I will take a look at the PS Commandlet source more closely and see what it does. I saw you had already some possible code execution candidates for the cause. Let me find the time so we can figure this out together.

Tried it in vm as suggested. Failed again.

Giving up now.

M.
----------------------------------------------------------------------------------------------------------

PS C:\WINDOWS\system32> Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic at
https:/go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): y

PS C:\WINDOWS\system32> Install-Script -Name Get-WindowsAutoPilotInfo

PS C:\WINDOWS\system32> Get-WindowsAutoPilotInfo -OutputFile $env:userprofile\desktop\Test.csv
Get-WindowsAutoPilotInfo : The term 'Get-WindowsAutoPilotInfo' is not recognized as the name of a cmdlet, function,
script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is
correct and try again.
At line:1 char:1
+ Get-WindowsAutoPilotInfo -OutputFile $env:userprofile\desktop\Test.cs ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-WindowsAutoPilotInfo:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

PS C:\WINDOWS\system32>

slicendice said:

Yeah, I saw that post. I tracked down the issue to being a permission error to connect to local computer. This means we can not connect to the Hyper-V Server on local host without elevated privileges. Maybe there is another workaround for this, by modifying some permissions somewhere...

I thought that adding user to Hyper-V Administrators group (one of built-in groups in W10) would help but no, same import error.

cereberus said:

Tried it in vm as suggested. Failed again.

For some reason the script was not installed, as can be seen in the error message:

cereberus said:

Get-WindowsAutoPilotInfo : The term 'Get-WindowsAutoPilotInfo' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Thanks anyway Martin!

Kari said:

I thought that adding user to Hyper-V Administrators group (one of built-in groups in W10) would help but no, same import error.

Yeah, I tried that too but it was a NO GO. :)

It sounds to me that the proper user credentials are not passed as an argument to Hyper-V or LocalHost...need to take a closer look at the code. I have it decompiled, but need to install VS and then import the code there so I can analyze what is calling what, how and when. The code is a big rats nest with calls back and forth and it's near impossible for me to figure it all out by just looking at the code. Tracing the execution in real time will help a lot, and I will also see what parameters and objects are passed between assemblies. :)