Dieser Fehler tritt explizit bei der Verwendung von ManagedPaths per WildCard Inclusion auf „/“ (-> ohne Explizit Inclusion „/“)
Heute wieder mal auf ein Relikt aus vergangen Tagen getroffen -> hier scheint es sich um etwas „übersehenes“ aus den alten Tagen zu handeln (oder jeder implementiert Custom-Soap-Services für SharePoint falsch).
Wenn man zum Beispiel folgendes PowerShell-Command verwendet, kommt es in diesem Szenario zu einer unschönen Fehlermeldung sobald er versucht WSDL/DISCO aufzulösen:
$webserviceurl = $site + "/_vti_bin/NintexWorkflow/Workflow.asmx"
$page = New-WebServiceProxy -Uri $webserviceurl -UseDefaultCredential;New-WebServiceProxy : The document at the url https://contoso.com/demo/_vti_bin/NintexWorkflow/Workflow.asmx was not recognized as a known document type.
The error message from each known type may help you fix the problem: - Report from https://contoso.com/demo/_vti_bin/NintexWorkflow/Workflow.asmx is The document format is not recognized (the content type is 'text/html; charset=utf-8')
- Report from 'DISCO Document' is 'There was an error downloading ' https://contoso.com/_vti_bin/NintexWorkflow/Workflow.asmx?disco' .Man sieht hier schön an der Fehlermeldung das er versucht auf eine andere SPSite zuzugreifen (welche es in diesem Szenario aber nie geben wird – und kann)
Es gibt aber zum Glück einen kleinen Workaround mit dem man einfach direkt den WebServiceProxy auf die WSDL Definition zeigen lässt – dann läuft es wie am Schnürchen (aber NUR den WebServiceProxy nicht die nachfolgenden Page-Responses und/oder Page-Requests.
$webserviceurl = $site + "/_vti_bin/NintexWorkflow/Workflow.asmx"
$page = New-WebServiceProxy -Uri $($webserviceurl+"?wsdl") -UseDefaultCredential;Over and Out