While configuring two universals on a single web server, to create a setup in which the functionality asked for in the topic linked above can be deployed, we run in some issues.
We like to setup a separate DNS record for each universal, such that depending on the DNS name the user is redirected to the correct login screen. Also on our development environment we like to have two universals, each using their own indicium, all on the same webserver, and have a separate DNS record for each universal.
In both scenarios we face the challenge of how to correctly perform the DNS mapping. Our main questions are currently:
- what would be the best place to have the redirection take place? Users should just go to the domain name, without providing a path, and routing/redirections based on the browsed DNS name must take place which makes them land on the correct login screen OR the correct home screen, dependent on if auto login can be performed.
- to which path should we redirect? We figured out that the standard login page can be found on https://<host>/indicium/account/ui/login, when calling the indicium application pool 'indicium’. However, it seems in that way we do not specify which universal must be used with this indicium. Therefore we think we must redirect to some other path and/or provide more information in some other way..
- Will this functionality work? In the documentation (see on https://docs.thinkwisesoftware.com/docs/deployment/universal the Note under Deployment/Step 1) it is stated that two universals will share certain cached values. Is this fixed after the releases of next friday? Will things work out in the routing logic of Thinkwise?
Best answer by Anne BuitView original
I will try to answer your questions one by one.
Strictly speaking there is no need for redirection at all. You will need to create two websites in IIS, each with their own subdomain as their host name. Your two DNS records can simply point to the IP address of the web server and IIS will automatically route requests to the correct website based on the host name. If you place the Universal GUI in the root of these websites, it will display the Universal automatically even if the user does not provide a path. If you want the Universal GUI to be placed in a separate folder, then you will have to create a Http Redirect rule on the website level, like this:
I think that this is perhaps where the confusion regarding your first question comes from. You should simply redirect to the Universal GUI (if you are redirecting at all, as stated above, this is not necessary). The Universal GUI will automatically redirect to Indicium if necessary and specify the correct return URL. If you are already signed in, this should also work as expected.
If the Universal GUIs are hosted on different subdomains, which they are in this example, then the browser will have no issue differentiating between the local caches.
So, in short:
I hope this helps.
Thanks for your answer. I was indeed slightly off with my way of thinking. However, some questions arise from your answer.
As you might know we host our software on AWS, with Universal+Indicium on Elastic Beanstalk. The configuration as you describe in your answer must be set up via the application deployment package logic/functionality of AWS Elastic Beanstalk. According to https://aws.amazon.com/blogs/developer/multi-app-support-with-custom-domains-for-net-and-aws-elastic-beanstalk/ this is quite difficult, or at least not the standard way of deploying IIS sites/apps on Elastic Beanstalk.
Could you please provide us with an example how to setup the configuration you describe on Elastic Beanstalk?
Did you also test that the functionality you will deliver next friday is tested in an/our AWS setup with multiple universals?
Moreover there seems to be a contradiction between your answer here and the answer you gave under the linked Idea. In the answer here you state that we need 'a Universal GUI and an Indicium in each of these websites’, while in the answer on the idea you ensure that 'this would work with using 1 IAM, 1 Indicium and multiple different Universal GUIs (1 for each setting)’. Maybe you can also take away our confusion here. :)
I’ll start with your final question, as this is also relevant to your other questions.
You don’t need two Indiciums and I didn’t mean to imply that you do. It will work the same way with a single Indicium, which can be placed in either of the two websites or even in a third website. I was simply trying to incorporate this question in my previous answer as well:
What you need is:
Not specifically, no. But the feature that was mentioned in the linked idea has no relation to the choice of web server or hosting platform. The only thing that matters in that regard is being able to set up two Universal GUIs with their own sub domains and corresponding DNS records on a single EC2 server. Which brings me to your final question.
I know that it is possible to use remote desktop to connect to the EC2 instance and then follow the steps from my initial answer. I also know that this is not your desired solution, but it leads me to believe that it should be possible to do the same thing using scripts. It is really a matter of what does AWS allow you to do via deployments scripts.
I can’t give a full solution for this right now, but you should be able to create websites on EC2 server with CloudFormation. The Microsoft docs below explain the PowerShell command that can be used for this via the IIS Web Administration module.
And you should be able to target a specific website in your deployment package by using the IIS Web Application Name parameter in the parameters.xml file.
I hope this helps.
Unfortunately, when trying to get this working with the CloudFormation template we encounter a PowerShell error that we don’t get when running it manually.
We can’t find much AWS-specific guidance on it, but this seems like a potential explanation:
Since we want this to run in Production by 8th of Marche there is a bit of an urgency here. Do you have any additional direction or could we ask one of your Infra colleagues for support?
It sounds like a problem with differences in processor architecture of the instances that powershell is executed on.
Info on how to adapt the powershell scripts of the cloudformation template can be found here, which is marked as a solution for similar problems.
That's great to hear Richard, I'm glad it all worked out. We will look into adding additional information on this topic to our documentation.
Were there any additional pitfalls regarding the New-Website command or the parameters.xml, aside from the x64 version of PowerShell that you would like to share for our documentation? Or perhaps some other steps that were not mentioned explicitly in this topic?
Currently we are attempting to make things work in the TEST environment, with two universals and one indicium. We managed to make it work by configuring one iis website for each DNS, each website having an own universal, and each having a dedicated application pool in which one indicium application runs, which both have the same indicium source code.
I am not sure if this is what you meant by "one indicium with multiple universals”. An alternative would be to configure both universal's serviceUrl to the same url, in which case we have one iis site with an application and one without an application. However then we have that one website sort of redirects to the other website. Moreover I think that the /indicium path will not work in that setup for the website without application, since it is not configured as an application on that website.
I think what you mean is to configure both websites to use the same application pool with a single indicium application in it. For this to work we would need to configure this application such that it has multiple sites attached to it. However, I could not find a good example on how to do this, so I'm not sure if this is possible..
Could you please advise on what the right way to go is in this matter?
I don't think using the same Indicium folder is a good idea in this case.
They will use the same "Logs” folder which is not a big problem, but hey will also use the same “cache” folder.
This can give problems when one of the instances is restarted, because it will delete the files. In some cases the same files will of course come back but not in all situations!
I think what you are looking for is IIS Site bindings - you can add multiple hostnames to the same website. Though this will make it a bit harder if you want to host Universal in the root with a different config.json.
Could you specify what IIS powershell commands should be used to set it up as such?
I would expect:
indicium hosted on the Default Web Site as Application with AppPool ‘INDICIUM’
2 custom sites, each having a Universal GUI folder, which are both linked to the INDICIUM Application Pool
I maybe must choose my words different. I read Richards post as:
I just wanted to warn that I think it will cause problems with the "Cache” and "Logs” folder as it means Indicium will be run twice with this setup. Both with the same working directory - and interfering with the same cache folder.
But if this is not the case you can ignore my comment - I just wanted to make sure and prevent possible errors.
What we actually like to implement, as
@Arie V states, is a single application pool which contains a single 'indicium’ application. This application pool should be used by two different IIS Websites, each using its own universal. However I keep getting stuck on the creation of an application, since I need to provide a website at that point. Therefore, we thought it would be a good idea to attach the application pool to the 'Default Web Site’, and from there link the two universal websites to that website. However I cannot really find a good source on how to do this via Powershell commands.
So in short, the issue is how to (re-)use the same application and/or application pool in multiple websites, and also in a way that the paths "website1.com/indicium” and "website2.com/indicium” both exist and point to the same indicium application in the same application pool.
@Richard Elderman and @Arie V,
My suggestion was actually to have three websites, two that deliver the static content of the Universal GUI and don’t require an Application Pool and a third one that hosts Indicium and has an Application Pool. But I failed to consider that the third website would need to have a different subdomain, which leads to the issue of cross origin requests and cookies that will be blocked by the browser.
My suggested setup would work if the two Universal GUIs did not use a different subdomain, in which case you could even put all three of them in a single website. For instance:
However, this is not quite as nice as using subdomains. This could be fixed by adding a reverse proxy in front of it, which would do the following routing:
But this makes the architecture more complex. I’m not sure if you could add such routing in the Elastic BeanStalk loadbalancer which you already have. If so, then perhaps this wouldn’t even be that much more complex.
Your current setup does work somewhat, but Dick is correct that this might lead to issues with the Cache folder.
So both of my suggested options here are viable, but by far the easiest solution would be to simply use two instances of Indicium after all.