Re: [mssms] 1709 Compat Scan
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
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
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, Carlwrote: > 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. > > > > >
[mssms] 1709 Compat Scan
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]