<p>This was answered via StackOverflow by Kevin Lu:</p>
<p><a href="https://stackoverflow.com/a/66739852/1224614">https://stackoverflow.com/a/66739852/1224614</a></p>
<p>In short, the second suggestion he made to update to PowerShell 7 and adding the environment information worked. I also had to run the script to reregister the Azure agent on the target server.</p>

CC BY-SA 4.0
2021-03-22T20:07:32.787Z
2021-03-22T20:07:32.787Z
Rich Claussen
<p>Sometime in the last week, our pipeline started using <code>Expand-Archive</code> to open the <code>.zip</code> file during the &quot;IIS Web App Deployment&quot; step instead of 7-Zip. It does not appear that this was done by our team, so I'm presuming this may have been changed in DevOps.</p>
<p>We are deploying to Server 2012R2.</p>
<p>Several of our apps are okay with this, however <strong>one</strong> of them fails to expand. It <em>seems</em> as if this might be related to path length (this app uses some very deep folder nesting with Angular) since I can <em>manually</em> run the command successfully if I shorten the destination path.</p>
<p>The command that fails to runs on the server is:</p>
<pre><code>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoProfile -NonInteractive -Command &quot;Expand-Archive -Path &quot;C:\azagent\A3\_work\r1\a\thisistheazurejobname\drop\thisisourappsnamex.zip&quot; -DestinationPath &quot;C:\azagent\A3\_work\_temp\temp_web_package_8157628602055582&quot; -Force&quot;
</code></pre>
<p>If I reduce it to:</p>
<pre><code>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoProfile -NonInteractive -Command &quot;Expand-Archive -Path &quot;C:\azagent\A3\_work\r1\a\thisistheazurejobname\drop\thisisourappsnamex.zip&quot; -DestinationPath &quot;C:\azagent\A3\_work\_temp\short&quot; -Force&quot;
</code></pre>
<p>...it appears to work fine.</p>
<p>Obviously, I am speculating that it's a path-length issue, but evidence does seem to support it. Also, I reconstructed what <em>would have been</em> the 7-Zip command and it worked as expected:</p>
<pre><code>C:\azagent\A3\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba\0.184.0\node_modules\webdeployment-common-v2\7zip\7z.exe x -oC:\azagent\A3\_work\_temp\temp_web_package_8157628602055582 C:\azagent\A3\_work\r1\a\thisistheazurejobname\drop\thisisourappsnamex.zip
</code></pre>
<p>I looked at the advice here and found we are already using the setting:
<a href="https://igorpuhalo.wordpress.com/2019/08/29/overcoming-long-path-problem-in-powershell/" rel="nofollow noreferrer">https://igorpuhalo.wordpress.com/2019/08/29/overcoming-long-path-problem-in-powershell/</a></p>
<p>My hope is that someone knows what may have changed, can suggest a straightforward way to go <em>back</em> to using 7-Zip, or a way to make <code>Expand-Archive</code> to work.</p>

<azure-devops><windows><azure-pipelines><release>
Azure Release Pipeline Fails Using Expand-Archive Command
Rich Claussen
# Azure Release Pipeline Fails Using Expand-Archive Command

(Asked by: username_0 on 2021-03-19)

Sometime in the last week, our pipeline started using Expand-Archive to open the .zip file during the "IIS Web App Deployment" step instead of 7-Zip. It does not appear that this was done by our team, so I'm presuming this may have been changed in DevOps.
We are deploying to Server 2012R2.
Several of our apps are okay with this, however one of them fails to expand. It seems as if this might be related to path length (this app uses some very deep folder nesting with Angular) since I can manually run the command successfully if I shorten the destination path.
The command that fails to runs on the server is:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoProfile -NonInteractive -Command "Expand-Archive -Path "C:\azagent\A3\_work\r1\a\thisistheazurejobname\drop\thisisourappsnamex.zip" -DestinationPath "C:\azagent\A3\_work\_temp\temp_web_package_8157628602055582" -Force"

If I reduce it to:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoProfile -NonInteractive -Command "Expand-Archive -Path "C:\azagent\A3\_work\r1\a\thisistheazurejobname\drop\thisisourappsnamex.zip" -DestinationPath "C:\azagent\A3\_work\_temp\short" -Force"

...it appears to work fine.
Obviously, I am speculating that it's a path-length issue, but evidence does seem to support it. Also, I reconstructed what would have been the 7-Zip command and it worked as expected:
C:\azagent\A3\_work\_tasks\IISWebAppDeploymentOnMachineGroup_1b467810-6725-4b6d-accd-886174c09bba\0.184.0\node_modules\webdeployment-common-v2\7zip\7z.exe x -oC:\azagent\A3\_work\_temp\temp_web_package_8157628602055582 C:\azagent\A3\_work\r1\a\thisistheazurejobname\drop\thisisourappsnamex.zip

I looked at the advice here and found we are already using the setting:
https://igorpuhalo.wordpress.com/2019/08/29/overcoming-long-path-problem-in-powershell/
My hope is that someone knows what may have changed, can suggest a straightforward way to go back to using 7-Zip, or a way to make Expand-Archive to work.

**Tags:** azure-devops, windows, azure-pipelines, release


---

## 1 answers

### Answer by username_0 on 2021-03-22. Score: 1 | Accepted answer

This was answered via StackOverflow by Kevin Lu:

<https://stackoverflow.com/a/66739852/1224614>

In short, the second suggestion he made to update to PowerShell 7 and adding the environment information worked. I also had to run the script to reregister the Azure agent on the target server.


---

