This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(224.00000000000003, 62%, 31%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDC%3C/text%3E%3C/svg%3E)
Until recently we have been creating and testing private offers in the Azure marketplace. As of yesterday, all 7 of our offers are now showing the message "Invalid argument: uiDefinition" after clicking "Create" on the listing page.
In addition, I can see in the browser console log that there is a 403 authentication error, when requesting the artifacts from: https://catalogartifact.azureedge.net/privateartifacts/.../Artifacts/createUiDefinition.json This happens in both Chrome and Firefox. A colleague of mine is also experiencing the same problem so I believe I can rule out a change in my subscription.
Is there a problem in the authentication flow happening in the azureedge server?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(144, 35%, 23%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJV%3C/text%3E%3C/svg%3E)
We have been experiencing similar issues, escalated to ISV customer success team and they are working with Microsoft Partner Center support to troubleshoot. So far most of our Azure Application (Solution Template) offers, which uses CreateUiDefinition.json and MainTemplate.json have been affected.
It looks like MSFT has resolved the issue or reverted the changes implemented. I can confirm my Solution Template is functional again.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(278.4, 74%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBV%3C/text%3E%3C/svg%3E)
Also OK on our side.
On September 15, a platform change was implemented. This change was part of a broader infrastructure update and, unfortunately, unintentionally caused failures in deployment scenarios that relied on delegated SAS tokens, including the one you experienced.
Once the issue was identified, the engineering team promptly rolled back the change. Since the rollback, we have monitored the system using internal diagnostics and have not observed any further failures of this type.
And also fixed on our side too. Excellent!
We are also experiencing a similar problem since yesterday.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(307.2, 89%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECV%3C/text%3E%3C/svg%3E)
The same on our end. Started since yesterday.
An update - I believe the auth checks have been tightened up on the Azure marketplace, and there might have been a loophole that has been closed.
In our case, we had created offers which were never live, but were only up to the preview stage. We then used "preview audience" to restrict who could view them. On top of this we also had plans in the offers, and these plans were set to private with only one person's subscription included (not mine). I believe it is the "private plan" that was causing the issue, and I believe this should have always been a problem, but must have been a loophole to do with private/preview.
Once we opened the plans up to be public, we could again deploy them. However, unlike a UI update, this process of "review and publish" for the preview once changing private -> public took much longer, about 4h. The publish bar on the marketplace site mentions this though, so fair enough. It's just much longer than updating the app.zip.
If someone comes across this post, please be aware that you can't go from public -> private without ending the plan and creating a new one. For our situation going from private -> public is no problem. We are doing this in a "tester" marketplace account. We have a separate "seller" account.
Our plan is in the Azure Marketplace as a Private Plan and it is not able to be pulled out of the store to be deployed since Tuesday. The state of our plan is Published, we were able to deploy it to audiences in the last months
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(192, 39%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGD%3C/text%3E%3C/svg%3E)
Same thing affects us as well.