Question
Jordan Everett · Jun 4

Web Gateway Managing Multiple Management Portals

Hi all!

I'm currently trying to find out how to have one Web Gateway route to multiple servers Management Portal. The only thing that I have come up with so far is to potentially make different routes per server?

I have a development, test, and production server and I want to use the same Gateway server using IIS to do SSL/TLS encryption for the CSP pages.

Any ideas or recommendations to pull this off?

Product version: HealthShare 2017.2
0
0 113
Discussion (4)4
Log in or sign up to continue

Thank you guys! These definitely helped me out.

Not to dog pile on as the links provided above provide the information but I want to highlight this one in particular, as it was a big 'gotcha' for us and even a long time InterSystems consulting partner I was working with at the time.

You can do everything else right, but if you setup your URL prefix in IIS for dev to be, say, /dev, so URLs would be myhost.com/dev/csp/blahblahblah, but your instance name is IRIS or ANYTHING other than 'dev', you will fail and not understand why.

The link I shared is just a sub-section of the same link Alexander shared but it addresses this gotcha. You must use that command in terminal to set the prefix on the instance associated with the URL prefix you created for it to recognize it appropriately. Without it, the only 'prefix' that will work by default is the name of the instance itself.

Hint, you can specify multiple prefixes (if desired) in comma-delimited format. It mentions that as well but a reason I bring it up is it helps tremendously cut down on the number of separate IIS configs to maintain in mirroring situations because I can setup the main prefix for the VIPA (Virtual IP Address) but also add prefixes for the individual server identifiers so if necessary, we can directly go to the individual servers of the mirror, even if they're not the current primary, for maintenance tasks (upgrade prep, security/task syncs, etc).  In this way, it totally negates any need for the private web server to remain running on your instances (big security win) and keeps the amount of maintenance relatively low on the IIS (or other web servers) side as well.