Hi Community,
Back in Dec 2023, had a bit of fun (actually a lot) with installing new version of Web Scheduler 2023 (after a year using previous versions 2022) but eventually succeeded and was able to log in (well only through Edge, not Chrome or FireFox).
About two weeks ago or maybe even before that, I think something has changed across all Browsers (Chrome, Edge, FireFox, you name it) which didn't even allow us to get to IIS default website (the blue Hello page), so there must a Windows update or Browsers themselves which not letting to reach IIS via self-signed certificate, let alone Web scheduler (I am not too techy but I am sure there should be some workarounds for it, just don't want to follow massive blog post around this issue and break the system). Meanwhile I helped another friend with Web scheduler 2023 installation for their project which was successfully installed but out of the sudden stopped working around the same time (same issue with IIS itself not coming up on default blue page, as we were also using a self-signed certificate).
So in this case, this is how we resolved the issue (please note this is only a Sage partner personal experience and in no way related to Sage. For official advise always refer to your Sage partner or Sage support):
1. Due to resource limitation, we have decided to install Web Scheduler in the same Application server. For Web Scheduler DBs, they are also is installed in the same SQL server, and withing the same SQL Instance of Sage X3, however the SQL Instance collation is set to Latin1_General_CI_AS and language set to English_US to match the requirements of Web Scheduler databases (your Sage X3 DB collation itself might be different and that is fine).
2. Purchased a valid certificate and imported into IIS (in our case the certificate CN or Common Name set to our Sage server computer FQDN as we just want to use it internally. In your case consult this with your IT team for best course of action, if you want to expose Web Scheduler to the internet and also follow Sage documentation/advise)
3. Checked related Certificate is imported properly in mmc.exe (personal certificates) and also Internet options
4. Now IIS is coming up with both Chrome and Edge (confirm that first via Binding, before any attempt to install Web Scheduler)
5. Installed Web Scheduler and was able to import data from X3 > only using X3_Interface (and not X3_Interface GraphQL which is another challenge for us, keep reading if interested...)
When trying to use X3_Interface GraphQL, Analytics "Total Import" action complains about certificate not being valid and I think this is not the certificate that we have used for Web scheduler itself, I can only narrow it down to the self-signed certificate added to the port 8125 (via Host setup). For example https://localhost:8125 (replace localhost with your host name and port you might have selected for https), it would probably work though still Browsers might say the certificate is not valid, proceed? and you can get to log in page eventually.
For Web Scheduler > Analytics using GraphQL interface is also trying to reach out to https://localhost:8125/xterm/api and it can't do it because of this new security measure enforced by Browsers (in my opinion). If you set your Analytics log level at Debug and check the log in Program data, you will see Web Scheduler is trying to reach out to https://localhost:8125/xterm/api with the same error message.
So next thing I am thinking of trying is to purchase another valid certificate and apply to this port 8125 via Host setup (even though we want to use it only internally). So if you beat me on this or if you already know how to resolved this issue, please kindly care to share.
Re,
Victor
