Skip to main content

Powershell and SOAP




  • Official comment
    Permanently deleted user

    The most recent change to Cerberus modified the Cerberus.wsdl file. Near the bottom of the file you'll see a default SOAP service endpoint that reads like this:

        <service name="CerberusFTPService">
            <port name="CerberusFTPServicePort" binding="tns:CerberusFTPServiceSoapBinding">
                <soap12:address location="{{WSDL_PROTOCOL:xml_escape}}://{{WSDL_HOSTNAME:xml_escape}}:{{WSDL_PORT:xml_escape}}/service/cerberusftpservice" />


    When you request (for example) 'https://localhost:8443/wsdl/Cerberus.wsdl', Cerberus FTP Server replaces the fields surrounded by double-braces, {{ FOR_EXAMPLE }}, with the current SOAP service endpoint configuration.

    However, you're accessing the file directly, so Cerberus server doesn't have the chance to fill with your current config. In this case, New-WebServiceProxy gets confused by the double-braces and fails to parse the .wsdl file, throwing an exception.

    The simplest solution is to use the web admin listener to access the wsdl file. Cerberus will tell New-WebServiceProxy the correct default listener currently configured for your server and you won't need to set $CerberusFtpSvc.Url explicitly in your script.

    You might have a good reason not to use the URL, though. Perhaps you're optimizing and want to eliminate the extra request to the server, or your Cerberus FTP Server doesn't have a running Web Administration port, or Web Administration port is inaccessible to your SOAP client due to firewall isolation.

    In that case, you will need to make a copy of Cerberus.wsdl and replace the template parameters with the current configuration. Or, if you are setting the $CerberusSvc.url explicitly in your script (as you are), you may remove the <service> element entirely.

    Thanks for bringing this to our attention. We made this change to make Cerberus.wsdl appear dynamic as server configuration changed, but we did not anticipate the problem it causes when accessing the file directly. We'll take a closer look at this system and possibly change it in the future.

    Finally, please take a look at a recently-released document on our support site, Calling Cerberus SOAP API from PowerShell

  • Dana Anderson
    Product Support



    I will see if the development team has any availability to review your script. In the meantime, I would suggest taking a look at a new walkthrough we just posted on PowerShell and SOAP. I think this will help you work out your issue. 





  • Jason Murray

    Thank you Vincent.

    The only reason I used the local directory option was because reference the URL in the New-WebServiceProxy returns the following error:

    New-WebServiceProxy : The HTML document does not contain Web service discovery information.

    In fact, this is the error I am getting in the official HelloCerberus.ps1 script (with the $WSDLUrl variable set to the web address, not the local file address)

    I imagine once the sample script (or environment) is configured to work correctly then I would be in a good place to further troubleshoot my own script.

    I'm not sure what else to try here?  Any further insight would be great.

  • Permanently deleted user

    Hi Jmurray,

    Sorry you're having trouble with your script.

    It certainly sounds New-WebServiceProxy is able to reach the URL you're providing it with, but it isn't receiving any WSDL file. I suggest you try opening your Web Administration console in a browser, from the same computer you're doing your scripting from. Click the link for the WSDL file, which is along the left navigation bar (See below):

    If that works and you receive an xml file, great! Copy that URL to your script source in the $WSDLUrl variable.

    If that doesn't work, then something strange is happening. It's probably best to open a support ticket if this is the case.

    You should still be able to make a local copy of Cerberus.wsdl file with the double-brace fixups I mentioned in my earlier post, though, if you're eager to make progress.

  • Jason Murray

    Thank you Vincent!

    This helped specify the correct URL and the script works! The difference between what was in the script and what was shown in the web-gui link was very subtle, but significant.

  • Permanently deleted user


    I just want to note that I highly recommend testing your scripts in a non-production environment. The SOAP API is quite powerful. Mistakes can be quite... destructive. :-D



Please sign in to leave a comment.