We're attempting to run the DXA 1.7 upgrade script on our CM server. At first glance, this looks like an issue with IIS authentication settings, for the SDL Web site or one of its applications. However, we're tried every different combination we could think of (enabling Anonymous authentication for everything, disabling it, enabling/disabling Windows authentication, comparing our IIS settings to an environment where the upgrade script runs without issue, etc.). We also made sure the DXA .zip file was unblocked before unpacking it, as discussed here.

At this point, we suspect it is something to do with Local Security Settings, or some similar issue as described here. However, unfortunately, our server is pretty locked down, in such a way that we don't have access to make changes to local security settings, and getting access may be very difficult.

I was wondering if anyone has suggestions for what else the issue might be or for an alternative approach to getting the CM updated to DXA 1.7.

DXA Upgrade Script Error

  • To ensure that user which you logged in to running the PowerShell has admin access to Tridion to run the power shell to connect core service. Alternatively, you can also able to use content porting to upgrade your templates to 1.7
    – Velmurugan
    Commented Apr 16, 2018 at 8:07
  • Hmmm. Well this seems to be an issue with the import/export service, not the core service. But I guess it's the same idea. I'm quite certain the user running Powershell does have admin access. We were considering using content porter, but I suspect we will run into similar issues with the import/export service... Commented Apr 16, 2018 at 13:35
  • 1
    What is the version of SDL Web you’re using? Commented Apr 16, 2018 at 17:39
  • 1
    Are you able to perform an export or import with the user that is running the powershell? I am thinking that this is not an issue with the DXA installation but rather a setting that needs to be tweaked for content porter to support the authentication that you are using.
    – Shiva
    Commented Apr 16, 2018 at 18:16
  • We revisited this after finishing setting up Authentication through Active Directory and LDAP and the issue seems to be resolved. I suspect we had only partially complete the Authentication setup before, and this was causing some sort of block. Commented Apr 20, 2018 at 13:49

1 Answer 1


Looking at the provided trace and error, the problem happens on the “stream upload” endpoint of the Import/Export Service: the client doesn’t provide authentication but the server expects it (Windows auth).

The weird thing is that these “stream upload” endpoints are not supposed to use authentication (WCF doesn’t support streaming i.c.w. authentication), so the client is not to blame here.

Please check you IIS configuration for the webservices web app in the SDL Web website. It is supposed to allow Anonymous acces (next to Windows auth), so that some of the endpoints can be accessed without authentication.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.