Re: [mssms] 1709 Compat Scan

2018-01-26 Thread 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 <cen...@arifleet.com> 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 <cen...@arifleet.com> 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

2018-01-26 Thread 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 
<cen...@arifleet.com<mailto:cen...@arifleet.com>> 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

2018-01-26 Thread 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.
>
>
>
>
>