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.
Environment | Service | Backend |
---|---|---|
Test | net.tcp://host1:830/inPoint.Admin.Server | inPoint.Test |
QM | net.tcp://host2:930/inPoint.Admin.QSrv | inPoint.QM |
net.tcp://host3:930/inPoint.Admin.QSrv | inPoint.QM | |
Prod | net.tcp://host4:930/inPoint.Admin.Server | inPoint.Prod |
net.tcp://xhost:930/inPoint.Admin.Server | inPoint.Prod | |
https://xhost:443/inPoint.Admin.Server | inPoint.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.