Autopilot File Copy from Win32app Fails

Copper Contributor

I created a Win32app package containing a desktop URL shortcut, an ICO file, and the deployment scripts. The package deploys correctly to existing workstations, but fails during Autopilot. Manual synchronization after Autopilot does not correct the problem.


Install Script


if (-not(Test-Path "C:\Windows\Directory")) {

    New-Item -Force -ItemType Directory -Path "C:\Windows\Directory"


Copy-Item "image.ico" -Destination "C:\Windows\Directory" -Force

Copy-Item "shortcut.url" -Destination "C:\Users\Public\Desktop" -Force


Detect Script


$Icon = 'C:\Windows\SACHEALTH\image.ico'
$Shortcut = 'C:\Users\Public\Desktop\shortcut.url'

$IconExists = Test-Path $Icon
$ShortcutExists = Test-Path $Shortcut

$IconMatch = $IconMatch = if ((Get-Item $Icon).LastWriteTime -eq 'Tuesday, September 12, 2023 2:47:14 PM') {$true} else {$false}
$ShortcutMatch = if((Get-Item $Shortcut).LastWriteTime -eq 'Tuesday, September 12, 2023 2:48:54 PM') {$true} else {$false}

if ($IconExists -and $IconMatch -and $ShortcutExists -and $ShortcutMatch) {
    Write-Host "Detected"
    Write-Host $true

else {
    Write-Host "Not detected"
    Write-Host $false
I have a few Win32app packages that perform similar functions. All work as expected on existing devices, but not Autopilot.
4 Replies
Do you have any logs from when it failed during Autopilot? Does it need to be installed during Autopilot ESP? Could you add a Start-Transcript c:\windows\temp\log.txt at the start of the install script and a Stop-Transcript at the end to see what's happening during installation?
Any update?

@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.

Ah, took some testing but happy to hear that it's fixed! Thanks for the feedback