Version: 2020.3.2

Overview

The inPoint.Admin installation contains of four parts:

  • The server component: Installed as inPoint.Admin windows service. Is installed on every server where also the server components to be managed are installed (inPoint Server, Hybridstore, ...)

    The default installation folder for the server is:
    C:\\Program Files (x86)\\HS Europe\\inPoint.Admin.Server\\Server

  • The LoaderJob: Located also in the server installation folder and registered as Pam.Archive job. It is the connection between inPoint.Admin-Service and the Pam.Loader-Console (a part of the inPoint Server). This job is currently needed to create new tenants oder create / delete GSR's. So when this job is not installed/running/activated (or the Pam.Archive service is not running) this operation would fail.

  • The plug ins: Every inPoint.Admin service has a set of matching plug ins. (Currently HybridStort and Repository) Every plug in has a server and a client part.

    The installation folders for the plug ins are:
    %inPoint.Admin.Server%\\..\\Plugins\\Server\\%pluginName%
    %inPoint.Admin.Server%\\..\\Plugins\\Client\\%pluginName%
    where %inPoint.Admin.Server% is the installation folders of the inPoint.Admin service.

  • The inPoint.Admin client: This is the UI for inPoint.Admin. The client can be installed on any computer and communicates only with the service but never with some of the back end components (PAM.Server, Hybridstore)

    Exception: When adding new AD-Groups, to search for new groups a query to the the active directory is run by the client (so in this case, the current user needs read access to the AD)

    The default installation folder for the client is:
    C:\\Program Files (x86)\\HS Europe\\inPoint.Admin

Default installation by the Wizard

The default installation by the Wizard installs the inPoint.Admin server, the plug ins, the LoaderJoband and the inPoint.Admin client on the same server machine into the default installation directories. To get the inPoint.Admin client working, you have to either define an environment or install the inPoint.Client

AdminDB

When installing multiple (redundant) agents take care that each agent managing the same environment is using the same backend and the same AdminDB.

Example with redundant backend:
NOTE: Using redundant backend is currently not well tested.

EnvironmentServiceBackend
Testnet.tcp://host1:830/inPoint.Admin.ServerinPoint.Test
QMnet.tcp://host2:930/inPoint.Admin.QSrvinPoint.QM
net.tcp://host3:930/inPoint.Admin.QSrvinPoint.QM
Prodnet.tcp://host4:930/inPoint.Admin.ServerinPoint.Prod
net.tcp://xhost:930/inPoint.Admin.ServerinPoint.Prod
https://xhost:443/inPoint.Admin.ServerinPoint.Prod

In this example we have 3 environments the Test environment has only one inPoint.Admin service and talks to the test installation of inPoint

The Prod environment provides 3 inPoint.Admin services bot talking to the inPoint prod installation. For this environment maybe only https://xhost:443/inPoint.Admin.Server is exposed via registry entry.

Test every environment needs its own AdminDB.

So if you start up using Prod, you first get the initial service https://xhost:443/inPoint.Admin.Server from the registry. Then this service tells the client that there are also 2 other endpoints. When communication with one endpoint fails, the next endpoint from this environment is used. But the client does not reload any data which was already loaded (therefore it's important that every endpoint talks to the same back-end)

An AdminDB is specified by DB-Connection-String, Schema and Table-Prefix. The "same" AdminDB means:

  • Same schema
  • Same prefix (oder no prefix)
  • Same DB-Connection-String

The AdminDB can be initially empty, all required tables (staring with {prefix}IPA_...) are then created when the inPoint.Admin service starts up.

Since the AdminDB has only status information, you can stop the services of one environment, drop all AdminDB-Tables (or cleanup them) and restart all services to get a new fresh AdminDB for this environment.

*NOTE: To automatically create new tables the database-user needs DDL-Rights. Without this you have to create the tables manually.

the AdminDB contains also the AdminDB-Log. To cleanup this tables you can create a SQL-Scheduler or use the provided SQL-Script for setting up a scheduling task (for SQLSERVER only). This script deletes all entries older then 30 days.

When having troubles with the tables (missing or wrong columns?) do:

  • Stop Admin.Server (for all instances using this AdminDB)
  • Drop the tables
  • Ensure to drop the table {prefix}IPA_VERSIONINFO
  • Startup Admin.Server (for all instances using this AdminDB)
  • Because of the missing VERSIONINFO table inPoint.Admin tries to run a DB-Upgrade on all tables.

The AdminDB-Tables are:

  • {prefix}IPA_LOG
    has all recorded log entires.

  • {prefix}IPA_PLUGIN_STATE / {prefix}IPA_PLUGIN_STATE_CON
    has the state of all agents and all loaded plugins. When the contents get lost you have to restart all inPoint.Admin
    services for this environment. You mas have to clean this table if you get obsolete information on the welcome page of inPoint.Admin.

  • {prefix}IPA_LOADER_JOB
    {prefix}IPA_LOADER_JOB_IN
    {prefix}IPA_LOADER_JOB_OUT
    has the requests for the LoaderJob, all needed input data and the result data. If you remove a request in the UI the entries in this tables are removed.

  • {prefix}IPA_VERSION_INFO
    has the version information and is needed to detect upgrades for the AdminDB

inPoint.Admin Client

When there are multiple environments defined on startup the user has to choose one of the environments. The environments are listed with {key}: {description}.

For environments defined in [HKLM\...\inPoint.Admin\Environment] {key} is the name of the registry folder and {description} is the default string from the registry folder.

For environments defined in [HKLM\...\inPoint\Environment] {key} is the name of the registry folder and {description} is the service URL calculated from the default string from the ServiceUrl registry key.

After selecting one environment the available plug-ins are downloaded.

When there are some warnings or errors the window stays open. Else it automatically closes after the downloads where completed.

Then the main window opens and the welcome page is shown:

In this case, two plug-ins where downloaded - but they are still unloaded by the client. The status tells that the service successfully loaded and initialized this plug-ins. When you expand the lines you get details of the service endpoints for each plug-in and the inPoint.Admin application itself.

Client Arguments

The client accepts the following arguments at the command line:

  • inPoint.Admin.exe /lang:de
    Starts the client in the selected UI language. This arguments overrides the setting
    <add key="language"> value="de" /> in the inPoint.Admin.exe.config

  • inPoint.Admin.exe /env:otherEnv
    Starts the client and selected the specified environment. This hides the environment selection window.