Erik Geurts

If all you did was deleting "legacy users", then it is unlikely you deleted advertisers as well. So it seems you like you may have accidentally deleted these advertisers themselves. Unfortunately, there is no way to get them back other than to restore a database backup from before you did these things.

An ad blocker will work in such a way that the browser won't connect to the ad server at all. Hence you're ad server won't even have a clue that someone has an ad blocker installed.

They made that plugin at https://www.ip2location.com/developers/revive-adserver , they should support it.

For support on products by IP2Location, please contact their support dept.

The javascript invocation code automatically switches from http to https if it runs on a webpage that's also https (that includes any javascript invocation code you already have on your pages). And I think when you access the Revive Adserver UI over https and have it configured correctly, new iframe invocation code will be generated for https.

That is actually the solution that the OP has tried and which doesn't help. So it must be something else...

Nothing needs to be done to Revive Adserver itself. It's a webserver configuration issue. If the current invocation code of your existing zones specifically points to http://... just configure the web server that runs your ad server to work over https, and then change the invocation code from http://... to https:/// If your banners happen to refer to externally hosted images that are entered with http:// you will have to update those as well.

That is not possible. You can assign a weight to a remnant campaign, the system will calculate the probability of delivery by putting that weight into the perspective of the total weight of all active banners on each zone. See http://documentation.revive-adserver.com/display/DOCS/Creating+a+Campaign

Sounds like you want to copy what WeTranser does. A wallpaper is essentially nothing more than just an image, albeit a large one. Revive Adserver can be used to traffic banners that are images, and link them to a zone. You can then do a request to that zone zone, to serve up one image after another.

I would recommend to put the MaxMind files in their own folder somewhere on the server outside of the Revive Adserver folders. That way when you perform an upgrade in the future, these MaxMind files will not be affected and geotargeting will continue to work. See http://www.reviveconsultant.com/articles/choosing-a-smart-location-for-a-revive-adserver-installation/

There is no technical minimum, but 24 or even a few hundred a day results in a statistically insignificant delivery probability.

It needs to be the full path of the file on the server, not relative to your Revive Adserver installation location.

You need to set the full path of the file(s), so the location and the filename(s), not just the folder.

See https://www.revive-adserver.com/blog/release-candidate-for-revive-adserver-v4-0/ which introduces new browser and operating system targeting capabilities.

See https://www.revive-adserver.com/blog/release-candidate-for-revive-adserver-v4-0/ which introduces new browser and operating system targeting capabilities.

See https://www.revive-adserver.com/blog/release-candidate-for-revive-adserver-v4-0/

Your suggestion only really applies if your own config file is referring back to the default config file, or the other way around, for some odd reason. Normally, that won't be the case.

This is probably not a generic solution. Normally, a config file won't rely on the existence of default. So in your case there must be something special and non-standard.

if he knows how, he should share that with the world. But I guess he's mistaken.

If the ad being served by your ad network initiates a redirect, there is nothing that can prevent it.

Your question is unclear. Can you please explain, perhaps including a screenshot or example?

This is not possible when using the javascript invocation code. You could perhaps build something within your own site that repeatedly calls them.

Exactly, spot on.

If you see a page that you're about to install even when it's really an attempt to upgrade, it means the upgrade wizard can't connect to your database, therefore can't find the existing tables and thus considers it a new install. Most often this is a MySQL permissions problem, and not anything in the application itself. Instead of proceeding with the process, it's best to first make sure that the database can be connected to.

@Reid We had a very similar case yesterday. It was the same file, downloaded from that same location you mentioned on Tuesday of this week. We downloaded it again today (and it had changed since Tuesday, surprisingly). Once uploaded on the server, geotargeting started working again. My two cents: somehow the file you found earlier on maxmind.com was wrong, and it was corrected after they found out.