hi, i have tried this today. .htm pages will be forwarded correct to my prtg webserver and i can login. but i have problems with .css and .png files. they are missing. here are the logfile from iis.

can you find what is going wrong?

thank you.

2015-01-05 22:30:16 192.168.7.141 33649 192.168.7.241 80 HTTP/1.1 GET /css/prtgmini.css?prtgversion=14.4.14.3789__ - 5 Connection_Dropped www
2015-01-05 22:30:16 192.168.7.141 33654 192.168.7.241 80 HTTP/1.1 GET /css/prtgmini.css?prtgversion=14.4.14.3789__ - 5 Connection_Dropped www
2015-01-05 22:30:16 192.168.7.141 33655 192.168.7.241 80 HTTP/1.1 GET /images/prtg_network_monitor.png - 5 Connection_Dropped www
2015-01-05 22:30:16 192.168.7.141 33657 192.168.7.241 80 HTTP/1.1 GET /images/prtg_logo_gray.png - 5 Connection_Dropped www
2015-01-05 22:30:16 192.168.7.141 33656 192.168.7.241 80 HTTP/1.1 GET /images/paessler.png - 5 Connection_Dropped www
2015-01-05 22:30:16 192.168.7.141 33667 192.168.7.241 80 HTTP/1.1 GET /images/prtg_logo_gray.png - 5 Connection_Dropped www

@schtebo: Could you try activating Failed Request Tracing in IIS and dig a little deeper? Also, please check the PRTG web server logs to check why the connection is dropped.

I have exactly the same problem. Are there any solutions?

@Ilya Nastenko: Do you have setup the failed request tracking as suggested above?
Best regards

I solved this problem. I disabled Output Caching for the site and now everything works.

Note: you need to disable the kernel cache.

I was sure I left a comment here before upgrading, but I guess I didnt post it properly. Anyway, problem came back after upgrading so was reminded of this, which is why Im back here.

Log story short, the file webroot/includes/reportheader.htm contains this line:

<base href='<#system type="requesthttpurl">' target='_top'>

It cause the following code to be inserted to the header of of page that uses this include file:

<base href='http://127.0.0.1:8081' target='_top'>

By setting this as a base, all URL references, for things such as images, use this as a prefix, so my browser sends a get for something like this:

http://127.0.0.1:8081/chart.png?graphid=-1&id=1002&avg=3600&sdate=2016-02-01-16-39-00&edate=2016-02-02-16-39-00&clgid=&width=850&height=270&graphstylefile=graphstyling.htm&animationandinteraction=1&datastylefile=graphdatastyling.htm&animationstylefile=graphanimationstyling.htm&graphstyling=baseFontSize=%2711%27%20showLegend=%270%27%20tooltexts=%271%27&datastyling=drawAnchors=%271%27%20anchorRadius=%271%27%20lineThickness=%272%27&refreshable=true

Can I remove the <base> completely from this file, which seems to be just fine? Shoud it use something other than <#system type="requesthttpurl">?

reportheader.htm is the only file containing the text requesthttpurl

@ckayfish: The tag <#system type="requesthttpurl"> is needed so all relative links are working. If everything is working for you, removing the line should not be an issue. However, you would have to do this after every update because currently we are not planning on removing the same.
Best regards

What use cases require the relative links to be different than the the URL of the page, which is causing this issue for anyone using Reverse Proxy? Anyway, is there another variable maybe I/we could use other than requesthttpurl, or alternatively is there a way for me to tell PRTG what this should be, rather than it building it for me from the IP/PORT?

The reports in this case need relative links to work. A workaround is not possible currently as we would have to change the code within PRTG.
Best regards

I will take your word for it that there is a case where the relative links on the reports page need to be different than the base of the page being loaded (which is used by default as the base for all relative links). I guess if the HTML for the report is hosted on a different site/host. It will certainly break the reports for anyoone using RP following the instructions here. I would use on outbound re-writing rule, but cant since using SSL.

I will simply continue to remove this from reportheader.htm, and if I ran into any problems will hardcode my actual base

One more thing, the links in the email are have the wrong protocol & port. There are liike http://prtg.mycompany.com:8081/report.htm?id=2713 & http://prtg.mycompany.com:8081/report.htm?id=2713), when the base should be like https://prtg.mycompany.com/. At least it get the hostname correct here, Im presuming from the DNS name entered

If we want to support using RP, perhaps in some future release there can be a spot where we enter a base URL, or somehow identify the protocol hostname and port that is actually used to access the website. This couple optionally replace how these links are currently built.

Am I missing something, or does everyone who uses RP experience these same issues?

The links in PRTG are built form the http/https configuration, the set up port and provided DNS name which in most cases works as the normal PRTG web interface is used instead of a Reverse Proxy. I forwarded your request to the development as well regarding full support of Revers Proxies.

Can i use xxx.yyy.nn/prtg url with URL rewrite? I add in Defaul Web Site new virtual part and create url rewrite in it as outlined above. But when I go to the link, I get a 404 error, always. In order to validate this design, I created another virtual directory to web interface of router. Redirection to the router works flawlessly. Why do I need this? I have SSL certificate for xxx.yyy.nn and I want use url rewrite for other services besides prtg.

@palyich: we currently have only tested forwarding a complete domain/subdomain to PRTG. An URL path has not been tested as currently there are some restrictions in PRTG itself which don't allow this. So currently it is only possible to forward the whole (sub)domain.
Best regards

@palyich, If not using SSL you could do an outbound re/write. It would change the outgoing HTML from "http://mydomain.com/" to "http://mydomain.com/prtg/" (unless prtg is already there?). This may be the only way. You could have another proxy site in front of it to offload SSL to.

I was thinking a rewrite rule on the root of the site may be able to be crafted to catch only and everything incoming to the root for PTRG, but I wouldn't want to attempt or manage that.

@ckayfish: You can sort of get around this as follows:

1) Ensure PRTG only listens on IP 127.0.0.1 (and is bound to port 80).

2) Ensure IIS only listens on your other IPs as described here: https://support.microsoft.com/en-gb/kb/954874

3) Bind the IIS site that you use for reverse proxying to port 80 (and 443 for HTTPS, I assume)

4) If you want to enforce HTTPS: Use URL Rewrite to redirect any HTTP traffic to HTTPS

5) Obviously proxy any request on port 443 (HTTPS) to 127.0.0.1:80

Now, PRTG thinks you are on http://yourdomain.com:80 and puts that link (sans the port number, as it's the default) into your ticket and notification emails. Technically that is still sort of wrong, but at least you can follow the link, as when you visit http://yourdomain.com this gets redirected by IIS to https://yourdomain.com, which then gets proxied to PRTG.

The crucial step here is step 2 as IIS by default listens on all IP addresses, even if you don't have a site bound to it. So, you would want to ensure it doesn't listen on 127.0.0.1. (Obviously if you still need IIS to listen on 127.0.0.1 you'll need to find another unused IP address which may be somewhat more tricky ...)

Just another vote for the "disabling the Output Cache resolved the issue" thing.

I'd missed that in the details, then spent a happy hour or two trying just about everything else I could to get ARR/URL Rewrite to deal with this correctly. That fixes it in two ticks (you have to entirely disable the output cache, which requires you to untick both boxes in the section of the site).

What's the status of <base href='' > tag? I have similar issues on the historic data page.

- prtg on my homeserver - IIS + ARR

but on the page https://my.domain.sample/historicdata_html.htm, I couldn't see the graphics. So I had to remove following line: <base href='<#if value="@aspdf" is="true" then="@srvurl" else="@requrl" varexpand="value,then,else">' target='_top'>

from the file: C:\Program Files (x86)\PRTG Network Monitor\webroot\includes\printhead.htm C:\Program Files (x86)\PRTG Network Monitor\webroot\includes\reportheader.htm

and everything works fine now.

Is it possible to implement this in your code?

Many thanx! kind regards, Bart Plessers

For all who having trouble in ARR 3.0 i've found the solution for the error "Sorry, the request cannot be processed, because the object ID is missing" when going to devices.

Make sure your URL Rewrite (on top level) have the Append Query string checked!

Got it working, no real problems, but... PRTG "thinks" it is using a non-secure connection (which it is, up to IIS on the same machine). When I log-in, it prompts me to change to a SSL connection (a I can't do that, according to the instructions).

Is there a way to kill this prompt, or even better:

I still think it would me much easier if the PRTG webserver would connect to the HTTP interface (Windows Communication Framework), in stead of connecting to the IP interface..