ESD Service

[naik_ajay]

What is the functionality of ESD service & FSG service on App Portal server.

1. We will be creating 2 App Portal Web servers & connect load balancer to it. will App Portal supports 2 Web servers connected via Load balancer?

2. Simultaneously2 ESD services will update the records in Database which will be common (only one database server). will it work properly?

3. App Portal daily syncs with SCCM as per time we have set up. in our new environment how can we handle this where we will be having 2 Web servers & one common database server?

4. if we stop the ESD service on one server then how application will function on this server?

5. How Flexera Serviced Gateway works? do we need to install FSG on both App Portal server? if we stop FSG on one server then how will it work?

[CharlesW · Accepted solution]

In response to your questions:

1. If you install multiple instances of App Portal, each tied to the same DB, then you need to ensure that the ESD Service is shut down on one instance.. You can only have one instance of the ESD Service running against a given App Portal DB. Beyond that, App Portal would not really know that it is being load balanced. I’m not aware of any special configuration which needs to be done from an App Portal perspective.

2. As mentioned, you can not have two instance of the ESD Service running at the same time. Doing so will cause issues, as both instances of the service would be trying to perform the same tasks.. The ESD Service performs repetitive background tasks such as collection inserts/cleans, status checks, policy refresh, data sync, etc. so you really only need to have one instance running.. Even if you were to shut down the ESD Service entirely, it would not immediately or visibly impact the end user experience.. Once the service was started again, it would pick up processing requests were it left off.

3. The nightly data sync with SCCM is performed by the ESD Service. As you should only have one instance of the ESD Service running at a given time, this will not be an issue..

4. The ESD Service which is still running on the other server will pick up any activity which is written to the DB on the other server.

5. You only need a single gateway... FNMS registers with the gateway to advertise its web service API calls.. App Portal queries the gateway to find out if FNMS is registered... If FNMS has registered with the gateway, then App Portal knows where FNMS is located. The location of the gateway is written to the App Portal DB. As such, any instance of App Portal will know how to find the gateway from the database.

NOTE: One think you should be cautious about would be changing the settings under the admin tab. In a single server environment, App Portal will clear the in memory cache of settings, and reload them. If you were to have multiple instances of App Portal running, then the other instance, where the settings were not changed, would not know about the updated settings.. As such, when you make a change to the settings, be sure to recycle the application pool on the other server to ensure that the new settings are picked up.. Also, it is a good practice to start the ESD Service after making a change to deployment settings, to ensure that the new settings are loaded.

[naik_ajay]

@CharlesW  Thank you very much for the detailed elaboration. much appreciated!

So App Portal administration (like changin settings, adding Catalogs) will be done from only one server on which ESD service & FSGService is running & the other server will be just to share the extra load?

[jdempsey]

---

@CharlesW wrote:

1. If you install multiple instances of App Portal, each tied to the same DB, then you need to ensure that the ESD Service is shut down on one instance.. You can only have one instance of the ESD Service running against a given App Portal DB. Beyond that, App Portal would not really know that it is being load balanced. I’m not aware of any special configuration which needs to be done from an App Portal perspective.

---

The other thing to be aware of is that some files get written to the web server during the course of operations (e.g. when you add a new icon or upload a new command script).  In addition to ensuring that the ESDService is disabled on all nodes except one, you also need to set up some kind of directory synchronization process that will keep those files/folders in sync across the multiple App Portal nodes.  One way you could do this would be to use the mirror capability of Robocopy set up as a Windows scheduled task.  If you don't do this, then any time you are accessing a web server that isn't the one where the file was uploaded, you won't see your icons on the catalog items (missing image) or you won't be able to execute the command scripts that may be tied to your workflow events.

---

@CharlesW wrote:

5. You only need a single gateway... FNMS registers with the gateway to advertise its web service API calls.. App Portal queries the gateway to find out if FNMS is registered... If FNMS has registered with the gateway, then App Portal knows where FNMS is located. The location of the gateway is written to the App Portal DB. As such, any instance of App Portal will know how to find the gateway from the database.

---

I'll qualify Charlie's response a bit.  Within Flexera Services, we normally install the FSG role on the App Portal server.  In a load-balanced configuration, you may want to install the FSG role on each node and register FNMS with both FSG's.  Then when you configure the FSG server within App Portal, you can specify "localhost" instead of the actual server name.  This will allow each node to look for the FSG role locally when querying for the FNMS endpoint.  If you only install the FSG on one server, then if that server goes down, you lose your resilience that you've added by load-balancing the App Portal server.  This isn't strictly required, but something to consider.

Note: The FSG is really only used to lookup the endpoint URL's for other Flexera products on the network, and that only happens when you save/refresh the settings on that Flexera Integration page.  Once the endpoint is looked up, the endpoint URL is saved in the database and reused each time it's needed until you save the settings on that page again.  Then we do the lookup again and save the new results to the database.  So strictly speaking, once you've configured the FSG and see the endpoints listed in the Flexera Integration settings UI, you don't really need the FSG role again unless you change settings on that page and save them.