Service Center is not being installed on new FE-server in Farm
Platform Version
11.18.1 (Build 38276)

I have added a new FE-server (let's call it ADAM) to a farm of an existing 6 FE's. On that initial install the ADAM FE was automatically included in the Global Deployment Zone of the other 6 FE's (the Deployment Controller is shared on one of the existing 6 FE's) - which was not my intention, but after that installation I could also see and access Service Center under IIS.

Then realizing my mistake - I created a new Deployment Zone (External) just for the ADAM FE - and removed the ADAM FE from the GLOBAL Deployment Zone and into the new External Deployment Zone. I then re-installed (maybe that wasn't needed, but that's what I did).

After that last step - IIS now looks really "sparse" - but I can deploy applications to it from LifeTime as can be seen from this picture

But Service Center is not here any more - so I cannot access it locally on the new ADAM FE server... I have never seen this scenario before - I was expecting Service Center to be on this new installation as well - but currently it is not.

What could be the cause of this? And do you know if it's going to be a problem for the "Testing" application that was successfully deployed?

I'm not sure it's related - but the environment health overview looks fine - except this IIS warning:

Any ideas on how I can make Service Center reappear on the new ADAM FE? Reinstalling and reconfiguring is not solving it. And I do not want the 'Testing' application to end up in the GLOBAL deployment zone - so the ADAM FE is NOT in there - only in the new External Zone.


Hello Ravn,

If ServiceCenter module is in the Global zone, as it is by default, and you have that new server only in the External zone then ServiceCenter will not be deployed there because of that: Only modules in the External zone will be deployed to that front-end because it is the only zone it belongs to.

You don't need to reinstall the platform to apply the changes to zones, modules should be deployed or removed automatically from each server when published.

The new front-end server was added automatically to the Global zone probably because that zone has the "Includes all Servers" option enabled.
The error in Environment Health is precisely because ServiceCenter is not deployed to that server and the URL that is checked for IIS status is /ServiceCenter/_ping.aspx.

I do however think that you should review your zones architecture because OutSystems recommends that the modules in System Components should be deployed to all the front-end servers, and for that the new server would need to be in the Global zone.

By adding it to the Global zone "Testing" would still not be deployed to the other old front-ends, but it would cause all the other applications to be deployed to the new front-end. If you don't want that last part to happen, create a new Internal zone with just the old servers, move all the other applications to that zone and keep only System Components and ServiceCenter in the Global Zone.

Thank you for the fast reply. 

I’m thinking that I need to go with the last suggestion and if I understand that correctly I will end up with 3 zones total:

1. Global (system components + Service Center)

2. A new Internal (all the old 6 FE servers incl. their applications)

3. A new External (just the 1 new ADAM FE and only the ‘testing’ application)

Is that correctly understood?

And do you know if moving the old application from global to the new internal will require any downtime in the environment (or replication) of these?

Best Regards


Yes, those three zones would be my suggestion.
You can change the deployment zone configured on the applications that will be in Internal and then apply the changes progressively as you deploy new versions to Production, or just create a solution with all the applications involved and publish them all at once. Either way, you shouldn't have any downtime like in regular deployments.

Hi Sergio,

Thank you for your valuable directions - I will remember to mark this post as 'solution'.

I have tried to make a drawing of my (new) understanding of the ideal deployment zone setup in our case - hopefully it will also be beneficial for others reading this post - I have a few additional questions at the end - but I'd appreciate any comments you might have :-)


For simplicity I have tried to draw it more simply - I believe they are equivalent in nature:


1. Does the above DZ architecture look sound?

2. Could the deployment zone address of 'Global' and 'Internal' be the same? (Or what would the consequences of that be... Maybe that the internal communication of 'Internal App A' would not work when it's communicating with 'System Components' because having the same DZA would point to both it's own DZA and the 'Global' DZA?)

3. Since we do not today have the 'Internal' zone - we have put 95% of our applications in the 'Global' - then I'm speculating if it isn't more easy to rename 'Global' to 'Internal' and then afterwards move the 'System Components', 'Outsystems UI' and 'Other Apps' to a new 'Global' (call it 'New Global'). My reasoning behind this is that it's easier for me to identify the Business Applications - than to do it for 'System Components' - would that be a good way to go about it?

Hello Ravn,

1. Looks ok to me.

2. If "global.mydomain.net" resolves to the same IP as "internal.mydomain.net" and that IP is of a load balancer that send requests to servers only in the Internal zone, OP01-06, then I don't see any issues happening because those servers have all the apps that are supposed to be in Global zone (because they are also in that zone), but you would have the load slightly unevenly distributed in internal requests between zones.

If it's the other way around and "internal.mydomain.net" resolves to the same IP as "global.mydomain.net", and it's a load balancer that sends requests to all the front-ends, then you would have issues because some requests for applications in the Internal zone would go to AZ01 that doesn't have them deployed (it is not in the Internal zone) and 404 errors would occur.

3. To identify all the modules of 'System Components', go to Factory -> Solutions and open the 'System Components' solution and check all the components associated, but I do believe you can rename the zones like that.

Thank you Sergio - you have been very helpful on these matters. For now a feel very enlightened and has marked your first answer as the 'solution'. I will now re-visit (and change) or Deployment Zone architecture.

Thank you.

Br. Allan

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.