RE: [mssms] Re: Do i need PXE to OSD clients that already have SCCM client?

[John Marcum]

I wouldn't ever put PXE first in the boot order.

From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On 
Behalf Of SCCM FUN
Sent: Friday, January 26, 2018 8:47 AM
To: mssms@lists.myitforum.com
Subject: Re: [mssms] Re: Do i need PXE to OSD clients that already have SCCM 
client?


When reading some of the blogs it says you need to set your NIC boot order on 
NIC's to have PXE boot at the top of the order.  If this isn't needed when 
reimaging a machine that is already an SCCM Client (like i discussed earlier) 
what's the need to have PXE 1st in boot order?



Thanks


From: SCCM FUN >
Sent: Thursday, January 25, 2018 8:52 PM
To: mssms@lists.myitforum.com
Subject: Re: [mssms] Re: Do i need PXE to OSD clients that already have SCCM 
client?


Awesome, thanks to everyone who answered, very helpful.


From: listsad...@lists.myitforum.com 
> on 
behalf of Jason Sandys >
Sent: Thursday, January 25, 2018 8:10 PM
To: mssms@lists.myitforum.com
Subject: Re: [mssms] Re: Do i need PXE to OSD clients that already have SCCM 
client?


No, PXE is not needed for this scenario (see Mike Murray's previous reply). You 
are correct that the boot image is staged to the local system when a task 
sequence deployment is kicked off via software center. The system then reboots 
into this staged boot image.



Also, PXE is never required for OSD.



J



From: > 
on behalf of SCCM FUN >
Reply-To: "mssms@lists.myitforum.com" 
>
Date: Thursday, January 25, 2018 at 6:42 PM
To: "mssms@lists.myitforum.com" 
>
Subject: [mssms] Re: Do i need PXE to OSD clients that already have SCCM client?



So if I have an SCCM client and i want to send OSD TS as available so user can 
kick off the rebuild, PXE is always needed?  I thought when they kicked it off 
from software center, it copied something down locally so when the machine 
reboots it "gets" to SCCM and doesn't need PXE?  I thought PXE was only needed 
for bare metal installs and not rebuilding current machine that is already SCCM 
client?



Am i wrong about this?



Thanks





From: listsad...@lists.myitforum.com 
> on 
behalf of Bradnan, Jerry 
>
Sent: Thursday, January 25, 2018 4:20 PM
To: mssms@lists.myitforum.com
Subject: [mssms] RE: Do i need PXE to OSD clients that already have SCCM client?



After the initial PXE Boot and OS file copy, it no longer uses PXE. It's the 
same process for USB media. It boots using the USB media, but after the OS 
install starts, the USB device is not needed.



You would use PXE to do the initial file copy and network connectivity. If you 
do not use PXE, then you would need a USB boot device, or some other process to 
boot the system for bare metal install of the OS.



Thanks,

Jerry



From: listsad...@lists.myitforum.com 
[mailto:listsad...@lists.myitforum.com] On Behalf Of SCCM FUN
Sent: Thursday, January 25, 2018 14:41
To: mssms@lists.myITforum.com
Subject: [mssms] Do i need PXE to OSD clients that already have SCCM client?



I know its a weird question, but I'm confused in regards to OSD and PXE.  If i 
have WDS/PXE setup and I deploy OSD TS to a current SCCM client when the 
machine reboots does it do anything with PXE or are all the files copied to the 
hard drive in the background while the machine is running?  Does it uses those 
files to boot/image the machine?  If it just uses the files copied onto the 
hard drive, is there any need for PXE?



Thanks

Re: [mssms] 1709 Compat Scan

[Adam Juelich]

a, I'm seeing that now.  That's interesting.  I'm assuming that's
associated with a Home Drive or an Apps Drive?  I would think it would
parse through items registered in Add/Remove Programs but maybe not?

On Fri, Jan 26, 2018 at 2:33 PM, Enley, Carl  wrote:

> Thanks we actually have Upgrade Analytics running but that would not help
> us here. The compat scan actually found files on our network file server
> and that is what I am trying to understand…why would it search there?
>
>
>
> *From:* listsad...@lists.myitforum.com [mailto:listsadmin@lists.
> myitforum.com] *On Behalf Of *Adam Juelich
> *Sent:* Friday, January 26, 2018 1:45 PM
> *To:* mssms@lists.myitforum.com
> *Subject:* Re: [mssms] 1709 Compat Scan
>
>
>
> Just a heads-up that you can utilize OMS in Azure for free to grab all of
> this data, chug through it, and tell you which apps won't work in Windows
> 10, which ones will be upgrade blocks, etc.  It also integrates into
> ConfigMgr with a nice dashboard and the ability to build collections off of
> that data.
>
>
>
> On Fri, Jan 26, 2018 at 7:47 AM, Enley, Carl  wrote:
>
> So we are moving along pretty good with our W10 1607 > 1709 upgrade via
> SCCM task sequence, mostly still in the IT deployment / Business pilot
> phase. I had a user contact me yesterday telling me the update failed so I
> did the usual digging through the log files in the panther directory and I
> found failure pretty quickly. There were 4 applications listed as hard
> blocks in the compatdata.xml file as shown below. I figured easy I will
> just remove the programs and go about my day or so I thought. I started
> poking around on the users machine and I couldn’t find any of the programs
> Windows was complaining about installed, nor could I even find a file or
> registry key that matched those programs.
>
>
>
>  IconId="afamgt.sys|56853beb5c5b62af"> BlockingType="Hard" StatusDetail="UpgradeBlock"/> Name="ManualUninstall" DisplayStyle="Text" ResolveState="NotRun"/> Program>
>
>
>
>  IconId="mcconsol.exe|b007179cc8857bb1"> BlockingType="Hard" StatusDetail="UpgradeBlock"/> Name="ManualUninstall" DisplayStyle="Text" ResolveState="NotRun"/> Program>
>
>
>
>  StatusDetail="UpgradeBlock"/> DisplayStyle="Text" ResolveState="NotRun"/>
>
>
>
>  StatusDetail="UpgradeBlock"/> DisplayStyle="Text" ResolveState="NotRun"/> CompatReport>
>
>
>
> I started digging deeper and found another log file in the panther
> directory called 2kP-xumRk0W++Fnb.3.8.0.0_APPRAISER_HumanReadable.xml
> that had some additional information in it like where the program that was
> being blocked was located. So it turn out all of the programs that Windows
> was finding and causing the 1709 upgrade block are files buried out on a
> network drive that everyone in the company has mapped? Why would the compat
> scan search mapped network drives for program compatibility, this can’t be
> the expected behavior can it?
>
>
>
> 
>
> 
>
>
>
> 
>
> 
>
>
>
> 
>
> 
>
> 
>
>
>
> 
>
> 
>
> 
>
>
>
>
>
>
>
> Here is the command line that my OS upgrade TS runs –
>
>
>
> Command line of Windows Setup upgrade: '"C:\windows\ccmcache\18\SETUP.EXE"
> /ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe
> "C:\windows\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback
> "C:\windows\SMSTSPostUpgrade\SetupRollback.cmd" /DynamicUpdate Disable
> /compat IgnoreWarning  /compat ScanOnly
>
>
>
>
>
> Here is what I get when I run the setup.exe manually from the ccmcache
> directory.
>
>
>
>
>
>
>
>
>
>

RE: [mssms] 1709 Compat Scan

[Enley, Carl]

Thanks we actually have Upgrade Analytics running but that would not help us 
here. The compat scan actually found files on our network file server and that 
is what I am trying to understand…why would it search there?

From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On 
Behalf Of Adam Juelich
Sent: Friday, January 26, 2018 1:45 PM
To: mssms@lists.myitforum.com
Subject: Re: [mssms] 1709 Compat Scan

Just a heads-up that you can utilize OMS in Azure for free to grab all of this 
data, chug through it, and tell you which apps won't work in Windows 10, which 
ones will be upgrade blocks, etc.  It also integrates into ConfigMgr with a 
nice dashboard and the ability to build collections off of that data.

On Fri, Jan 26, 2018 at 7:47 AM, Enley, Carl 
> wrote:
So we are moving along pretty good with our W10 1607 > 1709 upgrade via SCCM 
task sequence, mostly still in the IT deployment / Business pilot phase. I had 
a user contact me yesterday telling me the update failed so I did the usual 
digging through the log files in the panther directory and I found failure 
pretty quickly. There were 4 applications listed as hard blocks in the 
compatdata.xml file as shown below. I figured easy I will just remove the 
programs and go about my day or so I thought. I started poking around on the 
users machine and I couldn’t find any of the programs Windows was complaining 
about installed, nor could I even find a file or registry key that matched 
those programs.









I started digging deeper and found another log file in the panther directory 
called 2kP-xumRk0W++Fnb.3.8.0.0_APPRAISER_HumanReadable.xml that had some 
additional information in it like where the program that was being blocked was 
located. So it turn out all of the programs that Windows was finding and 
causing the 1709 upgrade block are files buried out on a network drive that 
everyone in the company has mapped? Why would the compat scan search mapped 
network drives for program compatibility, this can’t be the expected behavior 
can it?

















Here is the command line that my OS upgrade TS runs –

Command line of Windows Setup upgrade: '"C:\windows\ccmcache\18\SETUP.EXE" 
/ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe 
"C:\windows\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback 
"C:\windows\SMSTSPostUpgrade\SetupRollback.cmd" /DynamicUpdate Disable /compat 
IgnoreWarning  /compat ScanOnly


Here is what I get when I run the setup.exe manually from the ccmcache 
directory.

[cid:image001.png@01D396BA.F2E677B0]

Re: [mssms] 1709 Compat Scan

[Adam Juelich]

Just a heads-up that you can utilize OMS in Azure for free to grab all of
this data, chug through it, and tell you which apps won't work in Windows
10, which ones will be upgrade blocks, etc.  It also integrates into
ConfigMgr with a nice dashboard and the ability to build collections off of
that data.

On Fri, Jan 26, 2018 at 7:47 AM, Enley, Carl  wrote:

> So we are moving along pretty good with our W10 1607 > 1709 upgrade via
> SCCM task sequence, mostly still in the IT deployment / Business pilot
> phase. I had a user contact me yesterday telling me the update failed so I
> did the usual digging through the log files in the panther directory and I
> found failure pretty quickly. There were 4 applications listed as hard
> blocks in the compatdata.xml file as shown below. I figured easy I will
> just remove the programs and go about my day or so I thought. I started
> poking around on the users machine and I couldn’t find any of the programs
> Windows was complaining about installed, nor could I even find a file or
> registry key that matched those programs.
>
>
>
>  IconId="afamgt.sys|56853beb5c5b62af"> BlockingType="Hard" StatusDetail="UpgradeBlock"/> Name="ManualUninstall" DisplayStyle="Text" ResolveState="NotRun"/> Program>
>
>
>
>  IconId="mcconsol.exe|b007179cc8857bb1"> BlockingType="Hard" StatusDetail="UpgradeBlock"/> Name="ManualUninstall" DisplayStyle="Text" ResolveState="NotRun"/> Program>
>
>
>
>  StatusDetail="UpgradeBlock"/> DisplayStyle="Text" ResolveState="NotRun"/>
>
>
>
>  StatusDetail="UpgradeBlock"/> DisplayStyle="Text" ResolveState="NotRun"/> CompatReport>
>
>
>
> I started digging deeper and found another log file in the panther
> directory called 2kP-xumRk0W++Fnb.3.8.0.0_APPRAISER_HumanReadable.xml
> that had some additional information in it like where the program that was
> being blocked was located. So it turn out all of the programs that Windows
> was finding and causing the 1709 upgrade block are files buried out on a
> network drive that everyone in the company has mapped? Why would the compat
> scan search mapped network drives for program compatibility, this can’t be
> the expected behavior can it?
>
>
>
> 
>
> 
>
>
>
> 
>
> 
>
>
>
> 
>
> 
>
> 
>
>
>
> 
>
>  />
>
> 
>
>
>
>
>
>
>
> Here is the command line that my OS upgrade TS runs –
>
>
>
> Command line of Windows Setup upgrade: '"C:\windows\ccmcache\18\SETUP.EXE"
> /ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe
> "C:\windows\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback
> "C:\windows\SMSTSPostUpgrade\SetupRollback.cmd" /DynamicUpdate Disable
> /compat IgnoreWarning  /compat ScanOnly
>
>
>
>
>
> Here is what I get when I run the setup.exe manually from the ccmcache
> directory.
>
>
>
>
>

RE: [mssms] Re: Do i need PXE to OSD clients that already have SCCM client?

[Mike Murray]

It doesn't need to be at the top at all. You only need PXE if imaging a new 
machine or reimaging an existing machine from scratch. If you already have the 
client, no PXE needed.

From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On 
Behalf Of SCCM FUN
Sent: Friday, January 26, 2018 5:47 AM
To: mssms@lists.myitforum.com
Subject: Re: [mssms] Re: Do i need PXE to OSD clients that already have SCCM 
client?


When reading some of the blogs it says you need to set your NIC boot order on 
NIC's to have PXE boot at the top of the order.  If this isn't needed when 
reimaging a machine that is already an SCCM Client (like i discussed earlier) 
what's the need to have PXE 1st in boot order?



Thanks


From: SCCM FUN >
Sent: Thursday, January 25, 2018 8:52 PM
To: mssms@lists.myitforum.com
Subject: Re: [mssms] Re: Do i need PXE to OSD clients that already have SCCM 
client?


Awesome, thanks to everyone who answered, very helpful.


From: listsad...@lists.myitforum.com 
> on 
behalf of Jason Sandys >
Sent: Thursday, January 25, 2018 8:10 PM
To: mssms@lists.myitforum.com
Subject: Re: [mssms] Re: Do i need PXE to OSD clients that already have SCCM 
client?


No, PXE is not needed for this scenario (see Mike Murray's previous reply). You 
are correct that the boot image is staged to the local system when a task 
sequence deployment is kicked off via software center. The system then reboots 
into this staged boot image.



Also, PXE is never required for OSD.



J



From: > 
on behalf of SCCM FUN >
Reply-To: "mssms@lists.myitforum.com" 
>
Date: Thursday, January 25, 2018 at 6:42 PM
To: "mssms@lists.myitforum.com" 
>
Subject: [mssms] Re: Do i need PXE to OSD clients that already have SCCM client?



So if I have an SCCM client and i want to send OSD TS as available so user can 
kick off the rebuild, PXE is always needed?  I thought when they kicked it off 
from software center, it copied something down locally so when the machine 
reboots it "gets" to SCCM and doesn't need PXE?  I thought PXE was only needed 
for bare metal installs and not rebuilding current machine that is already SCCM 
client?



Am i wrong about this?



Thanks





From: listsad...@lists.myitforum.com 
> on 
behalf of Bradnan, Jerry 
>
Sent: Thursday, January 25, 2018 4:20 PM
To: mssms@lists.myitforum.com
Subject: [mssms] RE: Do i need PXE to OSD clients that already have SCCM client?



After the initial PXE Boot and OS file copy, it no longer uses PXE. It's the 
same process for USB media. It boots using the USB media, but after the OS 
install starts, the USB device is not needed.



You would use PXE to do the initial file copy and network connectivity. If you 
do not use PXE, then you would need a USB boot device, or some other process to 
boot the system for bare metal install of the OS.



Thanks,

Jerry



From: listsad...@lists.myitforum.com 
[mailto:listsad...@lists.myitforum.com] On Behalf Of SCCM FUN
Sent: Thursday, January 25, 2018 14:41
To: mssms@lists.myITforum.com
Subject: [mssms] Do i need PXE to OSD clients that already have SCCM client?



I know its a weird question, but I'm confused in regards to OSD and PXE.  If i 
have WDS/PXE setup and I deploy OSD TS to a current SCCM client when the 
machine reboots does it do anything with PXE or are all the files copied to the 
hard drive in the background while the machine is running?  Does it uses those 
files to boot/image the machine?  If it just uses the files copied onto the 
hard drive, is there any need for PXE?



Thanks

Re: [mssms] Re: Do i need PXE to OSD clients that already have SCCM client?

[SCCM FUN]

When reading some of the blogs it says you need to set your NIC boot order on 
NIC's to have PXE boot at the top of the order.  If this isn't needed when 
reimaging a machine that is already an SCCM Client (like i discussed earlier) 
what's the need to have PXE 1st in boot order?


Thanks


From: SCCM FUN 
Sent: Thursday, January 25, 2018 8:52 PM
To: mssms@lists.myitforum.com
Subject: Re: [mssms] Re: Do i need PXE to OSD clients that already have SCCM 
client?


Awesome, thanks to everyone who answered, very helpful.



From: listsad...@lists.myitforum.com  on behalf 
of Jason Sandys 
Sent: Thursday, January 25, 2018 8:10 PM
To: mssms@lists.myitforum.com
Subject: Re: [mssms] Re: Do i need PXE to OSD clients that already have SCCM 
client?


No, PXE is not needed for this scenario (see Mike Murray’s previous reply). You 
are correct that the boot image is staged to the local system when a task 
sequence deployment is kicked off via software center. The system then reboots 
into this staged boot image.



Also, PXE is never required for OSD.



J



From:  on behalf of SCCM FUN 

Reply-To: "mssms@lists.myitforum.com" 
Date: Thursday, January 25, 2018 at 6:42 PM
To: "mssms@lists.myitforum.com" 
Subject: [mssms] Re: Do i need PXE to OSD clients that already have SCCM client?



So if I have an SCCM client and i want to send OSD TS as available so user can 
kick off the rebuild, PXE is always needed?  I thought when they kicked it off 
from software center, it copied something down locally so when the machine 
reboots it "gets" to SCCM and doesn't need PXE?  I thought PXE was only needed 
for bare metal installs and not rebuilding current machine that is already SCCM 
client?



Am i wrong about this?



Thanks





From: listsad...@lists.myitforum.com  on behalf 
of Bradnan, Jerry 
Sent: Thursday, January 25, 2018 4:20 PM
To: mssms@lists.myitforum.com
Subject: [mssms] RE: Do i need PXE to OSD clients that already have SCCM client?



After the initial PXE Boot and OS file copy, it no longer uses PXE. It’s the 
same process for USB media. It boots using the USB media, but after the OS 
install starts, the USB device is not needed.



You would use PXE to do the initial file copy and network connectivity. If you 
do not use PXE, then you would need a USB boot device, or some other process to 
boot the system for bare metal install of the OS.



Thanks,

Jerry



From: listsad...@lists.myitforum.com [mailto:listsad...@lists.myitforum.com] On 
Behalf Of SCCM FUN
Sent: Thursday, January 25, 2018 14:41
To: mssms@lists.myITforum.com
Subject: [mssms] Do i need PXE to OSD clients that already have SCCM client?



I know its a weird question, but I'm confused in regards to OSD and PXE.  If i 
have WDS/PXE setup and I deploy OSD TS to a current SCCM client when the 
machine reboots does it do anything with PXE or are all the files copied to the 
hard drive in the background while the machine is running?  Does it uses those 
files to boot/image the machine?  If it just uses the files copied onto the 
hard drive, is there any need for PXE?



Thanks

[mssms] 1709 Compat Scan

[Enley, Carl]

So we are moving along pretty good with our W10 1607 > 1709 upgrade via SCCM 
task sequence, mostly still in the IT deployment / Business pilot phase. I had 
a user contact me yesterday telling me the update failed so I did the usual 
digging through the log files in the panther directory and I found failure 
pretty quickly. There were 4 applications listed as hard blocks in the 
compatdata.xml file as shown below. I figured easy I will just remove the 
programs and go about my day or so I thought. I started poking around on the 
users machine and I couldn't find any of the programs Windows was complaining 
about installed, nor could I even find a file or registry key that matched 
those programs.









I started digging deeper and found another log file in the panther directory 
called 2kP-xumRk0W++Fnb.3.8.0.0_APPRAISER_HumanReadable.xml that had some 
additional information in it like where the program that was being blocked was 
located. So it turn out all of the programs that Windows was finding and 
causing the 1709 upgrade block are files buried out on a network drive that 
everyone in the company has mapped? Why would the compat scan search mapped 
network drives for program compatibility, this can't be the expected behavior 
can it?

















Here is the command line that my OS upgrade TS runs -

Command line of Windows Setup upgrade: '"C:\windows\ccmcache\18\SETUP.EXE" 
/ImageIndex 3 /auto Upgrade /quiet /noreboot /postoobe 
"C:\windows\SMSTSPostUpgrade\SetupComplete.cmd" /postrollback 
"C:\windows\SMSTSPostUpgrade\SetupRollback.cmd" /DynamicUpdate Disable /compat 
IgnoreWarning  /compat ScanOnly


Here is what I get when I run the setup.exe manually from the ccmcache 
directory.

[cid:image001.png@01D39680.65CDE910]