"Unable to connect to the remote server" error and fix ($ssrs.Url = $WebserviceUrl)

[gduncan411]

tl;dr: To get this extension to work, and not "Unable to connect to the remote server" error when executing CreateCatalogItem, I had to add a $ssrs.Url = $WebserviceUrl to the ps file. Once in place, everything worked perfectly.

$type = $ssrs.GetType().Namespace;

**$ssrs.Url = $WebserviceUrl;**

#display datatype, just for our reference
Verbose-WriteLine "Got Namespace $type for SSRS..."; 

Long Story: Using the latest version of extension, the "Deploy SQL Server reporting files" task kept reporting an error; 2017-07-31T20:18:09.3147665Z ##[error]Microsoft.PowerShell.Commands.WriteErrorException: Unable to connect to the remote server

All the paths, settings, account, was able to deploy from VS, everything was correct, but there kept getting the error.

Finally I created a very simple version of the script, researched the SSRS Management API and found that all I had to do to make it work was add $ssrs.Url = $WebserviceUrl; in the WebProxy section.

After that, the extension worked perfectly...

Environment: SQL Server 2016 SSRS Native Mode TFS 2017.1 Extension version v1.5.1

Stripped down version of the script; SSRSTest.zip

Release Log with error; ReleaseLogs_34.zip

Screenshots;

[ygeelen-tb]

Thanks a lot for reporting this with extended explanation @gduncan411 ! @muziekklas could you please update the script?

[anton-kirschhock]

@gduncan411 Weird, that it doesnt work on your end. When I create the webproxy, I provide the uri to the new-webserviceproxy command.

Which Windows (and powershell) version are you using?

[gduncan411]

Windows 7 Enterprise N (x64) PS 4.0.0

Another data point. Added a Verbose-WriteLine to dump the $ssrs.url value right after creating the proxy...

Check out the result... (and this must be why it's failing in my enviroments and why I have to force set the .URL property) "2017-08-02T15:32:54.0448041Z [VERBOSE] >> URL Microsoft.PowerShell.Commands.NewWebserviceProxy.AutogeneratedTypes.WebServiceProxy1tServer_ReportService2010_asmx.ReportingService2010.Url for SSRS... -"

[anton-kirschhock]

"some text $variable.someparam" doesnt work. Try "some text" + $variable.someparam; (from the phone coding isn't that easy ;D)

[gduncan411]

Yeah, sorry, that was my screw-up...

Fixed that and found the issue (I think).

When the proxy is created the $ssrs.URL is set to HTTP We have HTTP turned off and can only use HTTPS

Check out the before/after output;

Sharing the setup again;

[anton-kirschhock]

So basicly, something is turning https to http..? Ill take a look when i am in the office

[anton-kirschhock]

@gduncan411 Got a few things which might caused this:

• Could you try adding a querystring ?wsdl behind the URL in the config (Example: http(s)://[ServernameFQDN]/ReportServer/ReportService2010.asmx?wsdl)
• Are you guys using any URL rewrite rule on the server?
• Is SSRS configured correctly to use HTTPS? Last resort, Can you execute this powershell script:

  $WebserviceUrl="";#Fill in this parameter
  $cred = Get-Credential; 
  $ssrs = New-WebServiceProxy -Uri $WebserviceUrl -Credential $cred;

  Then look what is inside $ssrs.Url (you simply can execute this in the powershell CLI)

[ygeelen-tb]

@gduncan411 Yes please add ?wsdl because the WebServiceProxy needs to be able to download the SOAP contract. And please check your Reporting Services Configuration Manager: it should display HTTPS on the Web Service tab page.

[gduncan411]

To be transparent, I'm like three levels away from any Report Server config. I'm just the guy trying to deploy reports from our TFS...

a) Adding ?wsdl made no difference (See image below) b) Rewrite? No idea, maybe? Our setup is very complex (see image below) c) Use HTTPS correctly? No idea. I do know that we can only access the /reports page via https and that I can browse and run reports via https d) PS executed and image attached. e) Request sent to our IT to get a screenshot of the Config Manager Web Service tab.

[gduncan411]

tl;dr Issue IS related to our environment and using another URL am able to deploy reports without setting the $ssrs.Url. In short, it's me, not you...

An IT guy got back to me (the guy who created the above diagram) and; a) confirmed that the https URL I was using is going to a load balancer, which is the thing blocking http calls b) Gave me a direct http URL to one of the servers.

Now I can deploy reports without setting the URL property.

Issue closed and thanks for all your help and for this great extension

[anton-kirschhock]

Good to know :) glad we could assist you