FAQ - Probleme mit der Einrichtung von OCT

Dieser Bereich diskutiert alle Fragen & Probleme, welche häufig im Rahmen einer Installation auftreten.

1. Wo finde ich Informationen bei Problemen?

• Falls während der Installation Fehler auftreten wird eine Log-Datei im Ordner des Installers erstellt.

• Die regulären Log-Dateien von OCT liegen im Verzeichnis “C:\ProgramData\Saxess Software\<Name des OCT Dienstes>\Logs”.

• Zusätzliche Fehlermeldungen werden unter Umständen in der Windows Ereignisanzeige ausgegeben.

2. Was mache ich, wenn der Installationsassistent nicht startet?

2.1. Mögliche Ursache: Windows SmartScreen

• Eine mögliche Ursache für das Ausbleiben eines Installationsstarts ist der “Windows SmartScreen” - ein Sicherheitstool zur Optimierung der PC-Sicherheit.

• Deaktivieren Sie den “Windows SmartScreen” damit das OCT-Installationsprogramm starten kann.

2.1.1. Beispiel: Windows 7 and Windows 8

• Öffnen Sie “Systemsteuerung” - “System und Sicherheit” - “Sicherheit und Wartung”.

• Suchen Sie alternativ nach dem “SmartScreen”:

• Öffnen Sie den Dropdown “Sicherheit” and wählen Sie “Einstellungen ändern”. Es öffnet sich ein neuer Dialog.

• Deaktivieren Sie den “SmartScreen” über die Option “Keine Aktion”:

2.1.2. Beispiel: Windows 10

• Öffnen Sie “Windows-Sicherheit” - “App- und Browsersteuerung”.

• Suchen Sie alternativ nach dem “SmartScreen”:

• Öffnen Sie “Einstellungen für zuverlässigkeitsbasierten Schutz”. Es öffnet sich ein neuer Dialog.

• Deaktivieren Sie “Potenziell unerwünschte Apps werden blockiert”.

3. Wo finde ich den OCT-Dienst und ist dieser aktiv?

3.1. Wo sehe ich, ob der OCT-Dienst erfolgreich läuft?

• Rufen Sie die “Dienste” (Windows) auf → Suchen Sie den OCT-Dienst, wobei die Benennung in der Installation festgelegt wird: 2. Installation "On-Premises" | Service-Name

• Starten Sie den Dienst ggf. neu.

• Merken Sie sich den Namen des Benutzers, unter welchem der Dienst läuft: 2. Installation "On-Premises" | 3.-Service-Konto

3.2. Wieso läuft der Dienst nicht?

Symptom: In der Liste der Windows-Dienste kann der OCT-Dienst nicht gestartet werden.

• Die Ursache lässt sich häufig über die Windows-Ereignisanzeige herausfinden unter “Windows-Protokolle” → “Anwendung” oder “Windows-Protokolle” → “System”

• Ein typisches Problem ist das fehlende .NET-Core-SDK.

3.3. Wo finde ich den Servernamen + Port (= URL) und den OCT-Administrator, unter welchem der Dienst läuft?

• Im Pfad “C:\ProgramData\Saxess Software\<Name des OCT-Dienstes> finden Sie die Datei: “appsettings.json.user” mit allen notwendigen Informationen.

3.4. Wieso kann ich die Webseite des OCT-Dienstes nicht aufrufen?

• Der angemeldete Benutzer hat keine Rechte bezüglich des OCT-Dienstes.

3.5. Wieso kann ich auf der Webseite das Tab "1.2. Globale Einstellungen" nicht sehen?

• Der derzeit angemeldete Benutzer hat zwar eingeschränktes Zugriffsrechte auf den OCT-Dienst, ist aber kein OCT-Administrator.

4. Wie deinstalliere ich den Dienst manuell?

Falls eine automatische Deinstallation über den Assistenten nicht möglich ist, befolgen Sie folgende Schritte:

• “CMD” als Administrator öffnen.

• Ermitteln Sie den Kurznamen des Dienstes (Eigenschaften auf dem Dienst).

• Geben Sie das Kommando “sc delete oct” ein.

  • Alternativ: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services” - löschen Sie den Eintrag für OCT.

• Starten Sie das System neu.

• Löschen Sie das Programmverzeichnis von OCT - es ist unter dem Pfad “C:\Program Files\Saxess Software\<Name des OCT-Dienstes>” zu finden.

• https://www.howtogeek.com/howto/windows-vista/how-to-delete-a-windows-service-in-vista-or-xp/

5. Wieso kann ich eine bestimmte Datenbank in OCT nicht aufrufen?

5.1. Hat der Dienst die nötigen Rechte auf der Datenbank?

• → 3. Einrichtung der Datenbank | 2.3.-Berechtigung-des-Dienstbenutzers

5.2. Hat der ausführende Benutzer die nötigen Rechte auf der Datenbank?

• Prüfung im SQL-Server-Management-Studio oder

• Prüfung in der Benutzerverwaltung bezüglich der Rechte.

5.3. Gibt es die Datenbank unter diesem Namen?

• Die Datenbank könnte unter falschem oder veraltetem Namen registriert sein - z.B. ein Schreibfehler.

6. Wieso kann ich nicht mittels Pivot oder CP auf die OCT-Datenbank zugreifen?

Diese Zugriffe sind vor allem im Zusammenhang mit Ergebnisdaten wichtig und notwendig.

6.1. Hat der Benutzer genügend Rechte?

• Als dieser Benutzer im SQL-Server-Management-Studio anmelden und die Ausführung des gleichen Lesebefehls durchführen.

• Falls der Zugriff mit einem Windows-Benutzer erfolgt, dann starten Sie SQL-Server-Management-Studio als dieser Benutzer neu.

6.2. Ist TCP/IP für diese SQL-Server-Instanz aktiviert?

• Prüfung im SQL-Server-Konfigurationsmanager → Computerverwaltung → Dienste und Anwendungen → SQL-Server-Konfigurationsmanager → SQL-Server-Netzwerkkonfiguration

7. Wieso wird das Zertifikat - bei der HTTPS-Einrichtung - falsch angezeigt?

(a) Bei der Installation mit HTTPS wurde nur der Rechnername ohne Domänenendung eingetragen. → Der Rechner ist nun nicht unter der Adresse “<rechnername>.<domäne>:<port>” erreichbar, sondern nur unter “<rechnername>:<port>”.
(b) Der Installationsassistent zeigt nicht das richtige SSL-Zertifikat an oder führt es fälschlicherweise als abgelaufen.

Anwendungsbeispiel:

• hostname, port usw. muss mit dem richtigen Computernamen ersetzt werden, auf welchem OCT installiert wurde.

• domäne_kurz entspricht beispielsweise “ad-testkunde”.

• domäne_lang entspricht beispielsweise “ad.testkunde.ac.de” (FQDN)

• application_id entspricht beispielsweise “{aaaabbbb123-ab12-cd34-ef56-usw.}”

Diese Applikations-ID kann frei gewählt werden!

• certificate_hash entspricht beispielsweise “0fab23de87ad81…”

7.1. Zertifikatshash

Das Zertifikatshash finden Sie mit dem Befehl:

certutil -store my

Identifizieren Sie zuerst das richtige Zertifikat, sodass Sie im Anschluss davon den Hash kopiert können:

• In der “appsettings.user.json”-Datei muss bei “URLs” der Wert angepasst werden zu: “https://ipadresse:port”

7.2. URL- und Zertifikatsbindungen

• Mit den folgenden Befehlen prüfen Sie auf vorhandene URL- und Zertifikatsbindungen:

7.2.1. Löschen der URL-Bindung

• Löschen Sie die falsche URL-Bindung - z.B. falls eine andere URL oder ein anderer Port genutzt werden soll - mit dem Befehl:

netsh http delete urlacl url="https:ipadresse:port/"

oder:

netsh http delete urlacl url="https:servername:port/"

• Falls der Hostname statt der IP verwendet wurde, sehen Sie sich den Eintrag der Prüfung auf URL-Bindung → FAQ - Probleme mit der Einrichtung von OCT | 6.2.-URL--und-Zertifikatsbindungen

7.2.2. Löschen der Zertifikatsbindung

• Löschen Sie eine falsche Zertifikatsbindung mit dem folgenden Befehl:

netsh http delete sslcert ipport=ipadresse:port

oder:

netsh http delete sslcert hostnameport=servername:port

• Falls der Hostname statt der IP verwendet wurde, sehen Sie sich den Eintrag der Prüfung auf URL-Bindung → FAQ - Probleme mit der Einrichtung von OCT | 6.2.-URL--und-Zertifikatsbindungen

7.2.3. Richtige URL-Bindung hinzufügen

Das Hinzufügen der richtigen URL-Bindung erfolgt mit dem Befehl:

netsh http add urlacl url=”https://ipadresse:port/” user=”domäne\user”

7.2.4. Richtige Zertifikatsbindung hinzufügen

• Den Zertifikatshash und die Applikations-ID finden Sie mit dem Befehl:

netsh http show ssl

• Falls bisher kein Zertifikat installiert ist, kann die folgende Applikations-ID aus dem Screenshot verwendet werden: “{ff24d6a6-90cd-4eef-9a47-7ca8f0c74177}”

netsh http add sslcert ipport=ipadresse:port certhash=certificate_hash appid=application_id certstorename=my

• https://docs.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh-http#add-sslcert → Diese Microsoft-Doku hilft, falls Parameterfehler bei diesem Befehl auftreten.

• Der OCT-Dienst muss neu gestartet werden und ist nun im Browser erreichbar über: https://<hostname>.<domäne_lang>:<port>

• Prüfen Sie, ob das Zertifikat vom Browser angezeigt und verifiziert wird (grünes Schloss links neben der URL):

In der Datei “appsettings.user.json” muss bei HTTPS-Installationen die IP-Adresse der Servers eingegeben werden, in der URL im Browser wird dann aber der Rechner mit Domänenendung aufgerufen.

8. Warum scheitert eine Abfrage von lokalen Umgebungen zu sxAzure?

• Eine Datenbank auf einem SQL-Server “X1” ist in Kombination mit einem Applikationsserver “Y1” in Benutzung. In dieser Datenbank gibt es eine Pipeline, welche Abfragen auf Datenbanken in der der sxAzure-Cloud macht. Wir nehmen an, dass dieses Szenario 1 erfolgreich funktioniert.

• Ein Back-up der oberen Datenbank oder eine völlig andere Datenbank ist auf einem SQL-Server “X2” eingespielt und diese auf einem Applikationsserver “Y2” registriert. Für Szenario 2 erhält man beim Ausführen eines Steps in einer Pipeline folgende Fehlermeldung:

8.1. Zugriff einer lokalen Umgebung auf sxAzure ermöglichen

• Um von einer lokalen Umgebung auf sxAzure zuzugreifen, muss der Port = 1433 in der Kundenfirewall geöffnet sein.

• Für das Szenario 1 mit dem Applikationsserver “Y1” ist diese Freigabe erfolgt, für das Szenario 2 mit dem Applikationsserver “Y2” jedoch nicht. Das erzeugt den oben gezeigten Fehler.

  • Auch das Verwenden eines Datenbank-Back-up erzeugt in diesem Szenario keine automatisch Freigabe!

8.2. Überprüfung des Freigabe-Status für Port = 1433

• Der folgende PowerShell-Befehl ermöglicht die Überprüfung des Ports:

Test-NetConnection 123.123.123.123 -Port 1433

• “123.123.123.123” steht dabei beispielhaft für die IP-Adresse des SQL-Servers.

• Es kann ebenfalls die URL des Datenbankservers, z.B. “octprovider.database.windows.net”, verwendet werden. Folgendes Beispiel zeigt eine solche Abfrage:

• “TcpTestSucceeded” gibt dabei das Ergebnis der Überprüfung an - “True” steht für erfolgreich und “False” für fehlgeschlagen.

• Für das obere Beispiel war damit der Test erfolgreich.

• Die gelbe Warnung beschreibt den Ping-Versuch der SQL-Datenbank auf Azure - dieser klappt für gewöhnlich nicht und muss nicht weiter beachtet werden.

8.3. Zugriff des (Kunden-)Servers auf die SQL-Datenbanken im Azure

• Die IP des Benutzer-/Kundennetzwerkes muss für jede SQL-Datenbank freigegeben sein.

9. Warum stürzt der Installationsassistent direkt zu Beginn ab?

Der Absturz erfolgt direkt beim Übergang aus dem Dialog “Windows-Dienst” in den Dialog “Anwendung-Dienstkonto”.

• Der OCT-Installationsassistent erkennt Azure-AD-Benutzerkonten generell nicht.

• Sind zusätzlich keine lokalen Benutzer in der Umgebung angelegt/verfügbar (z.B. ausschließlich AD-Konten), dann stehen dem Installationsassistenten keine Benutzer zur Verfügung.

• Somit stürzt dieser bei dem Versuch ab, im Dialog “Anwendung-Dienstkonto” die existierenden Benutzer zu laden.

Legen Sie einen lokalen Benutzer im Windows an.

• Ab der Generation 5.9 führt dieser Umstand nicht mehr zum Absturz, sondern zeigt eine Fehlermeldung an und erlaubt die Weiterführung der Installation.