Autopilot File Copy from Win32app Fails

Harm_Veenstra I was finally able to resolve the problem after a ton of testing and experimenting. It turns out that there were multiple 'quirks' that was causing the package to fail.

It's been several days since I resolved this, so my memory may by a bit off, but here's where's what I found. First, New-Item doesn't like the ItemType to be unquoted. I had to explicitly specify -ItemType, -Name, and -Path in quotes for this to work, otherwise New-Item would generate a file instead of a directory. Which leads to the second problem.

Obviously, if the resultant object from New-Item is a file instead of a directory, attempting to read anything inside that 'directory' is impossible. So, my detect script failed every time because it couldn't read the 'directory' contents.

The final trick that Intune through at me is that it doesn't seem to always replace the existing Win32app package after uploading a new one despite making sure to save the changes. When I compared my source icon and shortcut with those on a workstation, I found that modified dates didn't match. In fact, they were off by one second. I modified the files to update the dates, then repackaged everything and uploaded it to Intune. Lo and behold, the delivered files were still using the old dates. I simply deleted the entire Win32app deployment from Intune and built a new one with the recently updated Win32app package.

I decided to test this by only selecting this Win32app to be deployed out to a test workstation. After a full device wipe the entire process went straight through without a hitch. I had a fully functional Windows deployment with the Win32app package installed.

I repeated a similar process for all my other Win32app deployments. I can now confidently say that it is working exactly the way it's supposed to. We are now able to perform a full system wipe either remotely or locally and have the workstation come back to life with everything installed as expected.