PNP PowerShell Runbook cmdlet fails "A task was canceled" (Add-PNPPage)

Question

Hi,

I had a PowerShell script running perfectly and I then added some code to create a SharePoint page using the PNP.PowerShell module and I get this error:

Add-PnPPage : A task was canceled. At line:692 char:17 + ... $page = Add-PnPPage -Name "Accueil" -LayoutType RepostPage -Conne ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : WriteError: (:) [Add-PnPPage], TaskCanceledException + FullyQualifiedErrorId : EXCEPTION,PnP.PowerShell.Commands.Pages.AddPage

The same script runs perfectly fine in another tenant.

When running diagnosis, I get this:

We have investigated and identified that your runbook, RB-Projet-Provision, failed 4 times in the 7 days prior to support case creation. The most likely cause of the failure is because the runbook is using both Azure Rm and AzureAz cmdlets.

The most recent failure of RB-Projet-Provision is job Id, 4ce93214-c43c-4089-9e1d-9dbe53c9f087. It failed at line 692 in the Add-PnPPage cmdlet in the PowerShell module, PnP.PowerShell 1.9.0 The exception we detected is a WriteError exception. There are also both AzureRm and AzureAz modules loaded in the sandbox execution environment. This normally indicates that the runbook contains both AzureRm and AzureAz cmdlets.

The only Azure cmdlet I use is Connect-AzAccount. I tried upgrading AzureRM modules, then tried to delete them, but basic "default" versions (1.0.3) stay there. I also tried upgrading the Az module. I don't see the link between Add-PNPPage with Azure modules. Any suggestions?

Answer 1

Hi @Francis Laurin

Welcome to Microsoft Q&A! I regret the delayed response.

Can you please test if this script works on a machine outside of Azure Automation runbook? This would help isolate the issue to permission/scripting issue from Azure Automation.

Also, the error being received is generic TaskCanceledException. I would suggest using try{} catch{} in the runbook to be able to gather more details on the error as below:

try {  
    #Code that is/can throwing exception.   
}  
catch {  
    Write-Output $_.Exception.ToString() #Gets full details of the exception with stack  
    Write-Output $_.Exception.InnerException.ToString() #to get associated InnerException if any. This is usefull when the cought exception is different from the one that caused it.   
}  

You may also refer to this link for some common errors with runbook execution.

Please let me know if have any questions.

---
Please 'Accept as answer' and ‘Upvote’ if it helped so that it can help others in the community looking for help on similar topics.

Answer 2

I am sorry @AnuragSingh-MSFT , I missed your answer (somehow the tab was not refreshing even after several days!).

I finally found a solution by myself which I share here for reference.

This thread gave me a hint:
https://githubmemory.com/repo/pnp/powershell/issues/814

The issue was an interference between Az.Accounts and PNP.PowerShell. Indeed, when checking the module version number, I found in my bad tenant "Custom 2.4.0" while in my working tenant, I had "Default 2.6.0". I use Connect-AzAccount in the beginning of my script which interferes with client-side SharePoint pages PNP cmdlets.

Just deleting the module reverted it to default (2.6.0) and the problem was solved. There is no way I would have found it without the mentioned thread!

Update: Just want to point out that the "Update Az Modules" won't update any that was previously installed manually and marked as "Custom" which confused me. Indeed the diagnosis information from my first post pointed roughly to the right direction saying there was an issue with Azure modules, but the update button only did half the job.