Jump to content


anyweb

A deeper look at the Upgrade task sequence in System Center Configuration Manager (Current Branch)

Recommended Posts

from your log:

Windows setup in 'scanOnly' mode returned exit code hexadecimal 0xC1900200 ( decimal 3247440384) . Failing task sequence step.

this translates to

 

Does not meet system requirements for Windows 10: 0xC1900200 

 

Share this post


Link to post
Share on other sites
2 minutes ago, anyweb said:

from your log:


Windows setup in 'scanOnly' mode returned exit code hexadecimal 0xC1900200 ( decimal 3247440384) . Failing task sequence step.

this translates to

 


Does not meet system requirements for Windows 10: 0xC1900200 

 

I´m very well aware of that, but why is the WindowsSetupCompatibilityScanResults.ps1 failing to run?

I want the pop-up notification, I want the Logs to be moved to my server..

 

Like i said earlier, the log is from a virtual machine with only 1 GB RAM and the "Check Readniess" step disabled.. 

 

 

Share this post


Link to post
Share on other sites

it's failing to run the windowssetupcompatibilityscanresults.psq step here.

Command line "C:\_SMSTaskSequence\Packages\00100224\ServiceUI.exe"  -process:TSProgressUI.exe C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Hidden -NoProfile -ExecutionPolicy bypass -nologo -file WindowsSetupCompatibilityScanResults.ps1 returned 4294967295

probably because you are using the wrong version of serviceui.exe OR you made a mistake/edit in the powershell script which it does not understand,

 

 

Share this post


Link to post
Share on other sites
4 minutes ago, anyweb said:

it's failing to run the windowssetupcompatibilityscanresults.psq step here.


Command line "C:\_SMSTaskSequence\Packages\00100224\ServiceUI.exe"  -process:TSProgressUI.exe C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Hidden -NoProfile -ExecutionPolicy bypass -nologo -file WindowsSetupCompatibilityScanResults.ps1 returned 4294967295

probably because you are using the wrong version of serviceui.exe OR you made a mistake/edit in the powershell script which it does not understand,

 

 

Hmm, wrong version of ServiceUI sounds most likely then, the script is copied from this thread without and tweaks so shouldn't be anything wrong with it..

Thanks for your time, I'll take a look at the ServiceUI file and let you know how it goes :)

 

Btw, what Service UI should i use? I Copied mine from the x64 folder in the Deploymentshare\Tools directory, isnt that the one i need?

Share this post


Link to post
Share on other sites

you should use whichever version matches the os you are deploying

did you edit the powershell script in any way ?

Share this post


Link to post
Share on other sites
7 minutes ago, anyweb said:

you should use whichever version matches the os you are deploying

did you edit the powershell script in any way ?

No, the script is downloaded from your link, unzipped and pasted in the package folder.. I re-attach it here.

I´m trying to do an inplace upgrade for 1709 x64, so i picked the ServiceUI and WindowHide from the x64 folder.

WindowsSetupCompatibilityScanResults.zip

Share this post


Link to post
Share on other sites

what version of MDT did you use for that ?, if you use teamviewer i can connect and take a look at your setup if you want

Share this post


Link to post
Share on other sites
1 hour ago, anyweb said:

what version of MDT did you use for that ?, if you use teamviewer i can connect and take a look at your setup if you want

We are running 6.3.8450.1000, however I do belive it's working now..

While addding the steps to my task I was following your guide in the .docx you have published here. In that guide it says 

Quote

 

Step 2. Create a package

On your ConfigMgr server, in the sources share, create a folder called Windows setup compatibility scan results and place the WindowsSetupCompatibilityScanResults.ps1 PowerShell script in the folder. Locate, select and copy both windowhide.exe and ServiceUI.exe from the Sources\OSD\MDT\MDT2013u2\Toolkit\Tools\x64 folder as shown below.

 

But in the guide here in the forum it says

Quote

Step 2. Create a package

On your ConfigMgr server, in the sources share, create a folder called Windows setup compatibility scan results and place the WindowsSetupCompatibilityScanResults.ps1 PowerShell script in the folder. Locate, select and copy ServiceUI.exe from the Sources\OSD\MDT\MDT2013u2\Toolkit\Tools\x86 folder as shown below

 

 

 

So i replaced the ServiceUI.exe x64 with the x86 and that seem to have fixed it..I also removed the windowhide.exe, will I need it?

 

Anyways, thanks for helping me out and keep up the good work!

Share this post


Link to post
Share on other sites

Sorry to revive such an old post. I followed the guide and the WindowsSetupCompatibilityScanResults.ps1 script run and shows the results that it is supposed to, however, the variable WindowsSetupCompatibiltyScan never gets set. What could be wrong?

Share this post


Link to post
Share on other sites

hi Kevin,

don't be sorry, i'm happy to see you using it, can you please attach your smsts*.logs for me, you can scrub data from them first if you want

Share this post


Link to post
Share on other sites

I think I got it figured out. I was using lower case letters. I didn't realize it was case sensitive.

Share this post


Link to post
Share on other sites

I'm trying to get this to work in my lab, and I looked through the powershell script: WindowsSetupCompatibilityScanResults.ps1
Line 20 has this:  write-host $logstriing
Should that be changed to write-host $logstring?

Also, 

C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe

does not seem to be a valid path on any of my test machines?
I'll have to do some more testing.

-Jannis

Edited by Jannis Jacobsen

Share this post


Link to post
Share on other sites

yes well spotted, probably a typo in $logstriing...

as regards sysnative, try changing it to

C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe

 

Share this post


Link to post
Share on other sites
6 hours ago, anyweb said:

yes well spotted, probably a type $logstriing...

as regards sysnative, try changing it to


C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe

 

I got it working here with %windir%\System32\....
Guessing the x64 ServiceUI.exe does not have the virtual mapping for sysnative.
I guess the x32 version would work fine, but I like to use x64 on x64 systems, so this change is just fine :)
Thanks for a great solution by the way :)

This looks to be the perfect solution for upgrading our computers to the newest version of W10 on systems with both English and Norwegian System UI as default :)
If you happen to be in Oslo anytime, I'll buy you a beer :)

-Jannis

Edited by Jannis Jacobsen
  • Like 1

Share this post


Link to post
Share on other sites

I did some more tweaks, and I've gotten it working with scconfigmgr modern driver management.
So before applying the correct upgrade image, it downloads and stages the proper driver pack for the computer model, and during the upgrade, it will also install the current drivers for the model.

Pretty slick solution

-Jannis

Share this post


Link to post
Share on other sites

nice, you should share the updated code here :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...