Make an initialize module of it instead and check if the page has already been created?

If you don't want to add it to project and check it in of course. That would be my first option

why do you need to generate it, why not just deploy it?

The reason we have a job to generate the error pages is so that the navigation, footer etc are up to date on the static file. so if a page was removed from the site that previously was in the header an admin user could run this job to re-generate the error page and it would display the same as any other page on the site. this way if episerver is down for any reason the static 500error.html can be served and will not be out of date.

Yes fair enough, we usually remove navigation branding in favour of a more simplified version that's consistent across the 500 and maintenance static pages but I understand where you're coming from.

I don't think due to the nature of how jobs work you can't get them to work that way. Usually jobs are supposed to be run ideally on a dedicated instance so there's not really designed to be running on multiple. Plus the running status is all held in the database and wouldn't run again if already running. The IScheduledJobRepository used for programatically running jobs would just run them on the current instance.

Are you on the DXC or your own hosting? I'll have a think

The site is hoested on DXC. There are a couple of options we are looking at but i wanted to see if there was a simple way to trigger the job on all other servers, just to see if we could consider it as an option.

Its a bit of a long shot becuase i can't think of any other schenarios where you would need to run the same job on all servers.

let me know if you can think of anything.

Sam

It's an interesting one, the only thing I can think of that's clever and might work easily is having the header markup saved in blob storage. Then having the html file loading the content in with a client side include. Due to the fact the blob storage is across all servers it would be synced across them all with the standard functionallity. An out of the box solution.

Actually there's one other option, I assume your navigation is either in a settings page or is driven based upon the strucutre of the site/pages.

I believe the content events that support saving, deleting, moving ect get triggerd across all instances. So if you can work out which cotent changes are triggerd when you update the site settings page or event moving a top level page (if driven by site structure) you could use those to generate the page.

This means a) It works across servers and b) Only runs when it needs to.

You mention multiple servers on DXC but DXC instances are Azure web app instances rather than separate servers as such. This means that they should share a filesystem and so, when the scheduled job runs on one instance and writes the error page to that instance's filesystem, it should be the case that the file will also be accessible to all other instances. Are you getting instances where some see the error page and others don't?

As Daniel said, go for an initialisation module

Hi,

thanks for all the replies. I realize that there are other ways to approach this issue, but the specific question i am asking is if there is a way for a particular scheduled job to run on all server instances in dxc when its triggered manually? It runs on all servers when it is scheduled.

Its no problem if not, i just want to get a clear answer so i can work out if its an option our team can consider.

To answer that question directly - No. As Scott implied above, Episerver scheduled jobs always run on a single server whether they are manually triggered or run on a schedule.