winmadness

Eine reine Windows Open Source Anwendung für TOTP ist WinAuth https://winauth.github.io/winauth/ Somit kein Smartphone notwendig und der User kann die Anwendung auf seinem Windows Rechner verwenden. Weiterer Vorteil, man kann den Secure Key als Barcode und als Text anzeigen lassen. Somit kann man auf weiteren Windows Systemen bzw. Smartphones den selben TOTP anlegen / sichern.

Das Problem haben wir auch. Das direkte Öffnen von großen Office Dateien vom Server dauert "lange". Unsere Mitarbeiter kopieren die Datei vom Fileserver auf die lokale Festplatte und bearbeiten / speichern diese von dort. Nach erfolgter Änderung wird die Datei wieder zurück kopiert. Hat natürlich den Nachteil dass während der Bearbeitung die Datei auf dem Server nicht gesperrt ist bzw. das "Vergessen der Speicherung der geänderten Datei". Aber unsere Mitarbeiter sind soweit geschult und haben damit keine Probleme.

Ich würde das Ausführen des Scripts auch noch mit einem Passwort absichern. Dabei das Passwort natürlich nicht im Klartext im Script hinterlegen. Hierzu einige Hinweise von der KI: PowerShell Windows Anmeldeinformation speichern In PowerShell gibt es verschiedene Möglichkeiten, Anmeldeinformationen und Passwörter zu speichern und zu verwalten. Hier sind einige Ansätze: Get-Credential: Mit dem Cmdlet Get-Credential kann man interaktiv einen Benutzernamen und ein Passwort abfragen und ein PSCredential-Objekt erstellen. $cred = Get-Credential -Username "Benutzername" -Password (Read-Host -AsSecureString) Dieser Ansatz ist jedoch nicht sicher, da das Passwort als Klartext in das Script eingegeben wird. SecureString: Ein sichereres Verfahren ist die Verwendung von SecureString. Man kann ein Passwort als SecureString erstellen und dann in ein PSCredential-Objekt überführen. $secure_pwd = Read-Host -AsSecureString $cred = New-Object System.Management.Automation.PSCredential -ArgumentList "Benutzername", $secure_pwd Microsoft.PowerShell.SecretManagement: Microsoft bietet ein Modul namens Microsoft.PowerShell.SecretManagement, das es ermöglicht, Anmeldeinformationen und Passwörter sicher zu speichern und zu verwalten. Das Modul unterstützt verschiedene Speicherorte, wie z.B. Azure Key Vault oder lokale Dateien. Install-Module -Name Microsoft.PowerShell.SecretManagement cmdkey: Das cmdkey-Tool ist ein Teil von Windows und ermöglicht es, Anmeldeinformationen und Passwörter auf einem lokalen System zu speichern und zu verwalten. cmdkey /add:targetname /user:username /pass:wachtwoord PSCredentialManager: Das Modul PSCredentialManager bietet eine einfache Möglichkeit, Anmeldeinformationen und Passwörter auf einem lokalen System zu speichern und zu verwalten. Install-Module -Name PSCredentialManager Es ist wichtig zu beachten, dass die Sicherheit von Anmeldeinformationen und Passwörtern immer ein wichtiges Thema ist. Es sollte immer versucht werden, die Verwendung von Klartext-Passwörtern zu vermeiden und stattdessen sicherere Methoden wie SecureString oder spezielle Speichermodule zu verwenden.

Danke für das Feedback. Hast Du es schon mal in speziellen SAP Foren versucht. Ihr seid wahrscheinlich nicht die Ersten mit dem Problem. Eine weitere Idee. Den kompletten SAP Eintrag aus der Registry von einem funktionierenden Client exportieren und auf den neuen Laptop importieren. Des Weiteren alle Dateien aus dem Appdata/Local etc. Verzeichnissen auf das neue kopieren, sofern SAP dort ein Verzeichnis mit Konfigurationsdaten anlegt.

Danke für die ausführliche Beschreibung. Wenn ich alles richtig verstanden habe dann tippe ich auf ein fehlendes CA Root Zertifikat für das SAP Zertifikat, würde auch zur Fehlermeldung passen. Das Root Zertifikat stellt in der Regel der Softwareanbieter für eine Download zur Verfügung. Wie von Dir angedacht würde auch ich das Root Zertifikat „besorgen“ und auf dem Client PC als vertrauenswürdig importieren. In er verlinkten Anleitung sind insgesamt 184 Fundstellen für „certificate“ - gute Aussichten um eine Lösung zu finden 😏

Dir neue Fehlermeldung bezieht sich auf die vmxxx2, die alte auf die vmxxx - richtig? CertVerifyProcBuiltin for vmxxx2.domäne.local failed: Wenn ja dann auch mal das Zertifikat für vmxxx2 erneuern. Auf welcher VM ist SAP installiert, sind vmxxx und vmxxx2 zwei unterschiedliche Maschinen? Wenn ja welche Dienste laufen auf den VMs. noch ein Tipp: in einer Problembeschreibung so viele Infos wie möglich packen. Du kennst Deine Infrastruktur, der Leser nicht.

Ok, hier noch einige Ideen: evtl. fehlende Lizenz, also benötigt SAP für jeden Client eine Lizenz? evtl. Lizenz auf dem Server in SAP freigeben bzw. Client für den SAP Zugriff freigeben Evtl. blockiert die Server Firewall den Zugriff vom neuem Client über den „SAP Port“ Nachtrag: hat sich die Fehlermeldung im SAP Protokoll nach der Zetifikatserneuerung geändert? Wenn ja bitte posten. Sind auf dem Server oder Client in den Event Protokollen Einträge bzgl. SAP Zugriff vorhanden, nicht nur Fehlermeldungen, bitte posten.

Das abgelaufene Zertifikat entspricht mit seinen Angaben dem der Fehlermeldung. Der nächste Schritt wäre mit Hilfe eines SAP Spezialisten / Support die Bedeutung des Zertifikates zu ermitteln bzw. eine mögliche Erneuerung einzuleiten. Es ist nach meiner Meinung also kein Windows Problem, sondern SAP. An der Stelle bin ich raus.

Suche mal auf den Clients und der VMxxxx nach einem Zertifikat mit den Angaben aus der Fehlermeldung: CN=VMxxx,OU=B1,O=SAP,C=CN

Ich würde auf ein fehlendes SAP Zertifikat auf dem Client tippen. Überprüfe auf den anderen Clients ob diese Benutzer- / Computerzertifikate von SAP haben. Sieht so aus als erwartete die VMxxxx ein (Computer-)Zertifikat welches auf dem Client installiert werde muss. Unabhängig hiervon gerne an den SAP Support wenden, bevor das Rätselraten weitergeht

Hallo @emw, ignorierst Du meine Beiträge bewusst oder hast Du meinen Vorschläge schon getestet? Nur wenn Du uns Feedback gibst können wir Schritt für Schritt versuchen das Problem zu lösen. Wenn Du meine Vorschläge nicht benötigst oder nicht hilfreich findest, dann bitte kurze Info. Dann spare ich meine Ideen hierzu. Danke.

Ich würde erst einmal einen einfachen select machen der alle Felder incl. der CALCULATE Felder ausgibt. Damit Du sicher sein kannst dass die erwarteten Werte auch in den Feldern stehen. Danach ändere die folgende When Klausel WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND ([CALCULATE6] > 10 AND [CALCULATE6] <= 100) THEN [CALCULATE3]/100*3 auf WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND ([CALCULATE6] = 16) THEN [CALCULATE3]/100*3 und teste mit Rabatt 16%. Damit kannst Du prüfen ob auch wirklich der Wert 16 in der Abfrage funktioniert. Ich vermute nach wie vor dass der Inhalt von CALCULATE6 nicht vom Typ integer ist bzw. den erwarteten Wert enthält. Nachtrag: Als eine Möglichkeit könnte der Rabatt im Feld CALCULATE6 als Zahl mit Nachkommastellen z.B. 0,16 (bzw. 0.16) dargestellt werden.

Ich vermute dass das Calculate Field zum Zeitpunkt der Abfrage noch gar nicht „berechnet“ ist und somit der Wert immer 0 ist. Zum Testen eine der Abfragen in >= 0 ändern, z.B. ... WHEN ([TEXT23] = 'NEIN') AND ([TEXT59] ='K') AND [CALCULATE6] >= 0 AND [CALCULATE6] <= 100 THEN [CALCULATE3]/1*5 ...

Hallo @maddinx6, wenn Du den Zugriff von New Outlook auf Exchange Online blockieren willst, dann hilft Dir dieser Artikel von MS weiter. Ich gehe davon aus dass damit auch der bestehende Zugriff deaktiviert wird.

Eine Lösung für alle Programme von Drittanbietern gibt es meines Wissens nicht. Meine Ideen hierzu: Für EspoCRM gibt es ein Zusatzmodul für Synchronisation mit Outlook. Das Tool caldavsynchronizer ist ein Add-On für Outlook zur Synchronisation mit CalDAV und CardDAV (z.B. für Nextclolud). Evtl. einen "Synchronisationsrechner" mit Outlook und allen gewünschten Exchange-Konten einrichten.