flasher4401

Der User bin ich. Die Workstations loggen sich automatisch auf den vorgefertigten Konten ein und starten das Programm. Es gibt keine unterschiedlichen Konten/Profile für andere Nutzer. In meinem Fall ist ein Profil/Konto völlig egal, Hauptsache es existiert überhaupt eins, von daher kann ich die auch nach belieben Löschen. Es bringt nun aber überhaupt nichts darüber zu reden in welchem Ausmaß Profile/Konten von wem, wie genutzt werden, denn das hat nichts mit der eigentlichen Problemstellung zu tun. Das Problem ist aber wie beschrieben erst einmal gelöst. (Und ich hoffe es bleibt dabei.) Gruß

Der Fehler ist behoben. Der Eventlog war wie erwartet vorbildlich ohne Warnungen und Fehler, also lief es auf Try&Error hinaus. Da die Workstations, wenn sie einzeln angemeldet waren, das Programm ohne Probleme ausführen konnten, - so habe ich mir gedacht - musste das Problem entweder direkt bei der Freigabe am Server entstehen (Rechte, etc.), oder auf den Clients. So habe ich erstmal alle Rechte nochmal nachgeprüft und alles war natürlich wie ich es bei der Konfiguration eingestellt hatte. Dann war der nächste Schritt, weil ich mir gedacht habe, dass eventuell letzte Änderungen (vor einem Monat) in den Gruppenrichtlinien nicht richtig auf den gecachten Benutzerkonten auf den Workstations übernommen wurden und deshalb nun Konflikte bei der Verbindung Server - Client entstünden, neue Testkonten einzurichten und das Programm dann nochmal über diese auf den Workstations auszuführen. Siehe Da! Das Problem war gelöst. Also habe ich die vorherigen Konten einfach gelöscht und neue erstellt, da dort eh nur eine Serververbindung mittels Netzlaufwerk eingerichtet und eine Verknüpfung zum Programm auf dem Desktop erstellt wird. Es funktioniert nun zwar wieder, dennoch weiß ich nicht, was genau jetzt der Auslöser war. Gruß

Hier wird keine gemeinsame Access-Datenbank genutzt. Die vom Programm zu nutzenden Dateien liegen alle einzeln vor und das Programm regelt die Lese und Schreibzugriffe selbst..(Greift ein Client auf eine bestimmte Datei zu, ist sei für einen anderen Client gesperrt.) Die Programmarchitektur sieht keine Trennung von Front- und Backend vor. Das Programm wird auf dem Server installiert und über eine Freigabe direkt übers Netzwerk auf den Clients gestartet. Gruß

Was Windows Server + Netzwerke anbelangt, beschränkt sich das eigene Können auf Google und ausprobieren. Mit der Methode war es auch möglich das System voll funktionsfähig einzurichten. Nach mehreren erfolgreichen Probeläufen, wurde es dann auch erst gewechselt. Nur ist mir schleierhaft, warum, ohne manuelle Änderung am System, dieses nun nicht mehr richtig funktioniert und das zuvor beschriebene Verhalten aufweist. Solch ein Problem hatte ich vorher noch nicht und Google lieferte diesmal auch keine Lösung. Ich werde morgen Abend über weitere Ergebnisse berichten. Sollte ich morgen schon direkt auf die Fehlerursache stoßen, lasse ich es euch wissen. Ich wünsche noch einen schönen Restabend. Gruß

Gut, danke, wo soll ich denn dann am besten Anfangen, nach dem Problem zu suchen (nachdem ich mir mal den Eventlog zu Gemüte geführt habe) ? _____ Ja Chremasoft hat einen sehr guten, nahezu immer erreichbaren Telefonsupport, dieser beschränkt sich aber auf die Bedienung des Programms mit dem technischen Zusatz des Einspielens von Updates. Bei diesem Problem wird mir dort keiner helfen können. Gruß

Benutzerkonten / AD können durch irgendwelche falsch gesetzten Richtlinien beeinträchtigt worden sein. Beispiel nenne ich mal hier die Sicherheitsrichtlinie für die max. Gültigkeitsdauer eines Passworts, wo nach Ablauf der Frist, der User gezwungen wird ein neues Passwort zu vergeben. Ich weiß ja nicht inwiefern / ob es für Freigaben, etc. solche Richtlinien gibt und ob es irgendwo ein Fehler war in den Richtlinien eine bestimmte Einstellung auf "Nicht definiert" zu setzen und es deshalb zum beschriebenen Problem kommt. Gruß Edit: @XP-Fan: Nein, als mir das einfiel war ich schon wieder auf dem Heimweg.

Microsoft berechnet sich anständig was und gute Erfahrungen habe ich mit dem Support auch nicht. Einfache Probleme werden im Handumdrehen gelöst, aber bei so etwas weiß mal wieder keiner Bescheid. Der Telefonsupport des Programmherstellers beschränkt sich auf die Bedienung der Software. Dort technischen Support zu erhalten ist praktisch unmöglich. (Die letzte Mail, die an den technischen Support gerichtet war, wurde nicht zufriedenstellend nach knapp einem Monat beantwortet.) Im Endeffekt wird das Problem in Try and Error enden. Programm neu installieren, neue Freigabe erstellen, testen. Falls es dann nicht funktioniert: Neue Domänen-Benutzer für die Workstations einrichten, neu testen. Danach die Richtlinien zurücksetzen und testen, gefolgt vom Entfernen des DNS und DC's und der kompletten Neukonfiguration. Sollte gar nichts helfen muss man sich überlegen die Systeme komplett neu zu installieren, was bei dem entstehenden Aufwand natürlich vermieden werden sollte. Erreicht man nun durch irgendeinen Schritt wieder die Funktionalität, weiß man aber immer noch nicht woran es gelegen hat und man geht ein großes Risiko ein, denn die Chance ist groß, dass der Fehler eines Tages wieder auftritt. Gruß

Hallo. Ich habe ein wirklich dringendes Problem, was es schnell zu lösen gilt. Kurz: Das am Server freigegebene Programm lässt sich (seit heute) nur noch auf einem Client zur selben Zeit ausführen. Am Arbeitsplatz laufen 1x Windows Server 2012 R2 (DC) und 3x Workstations mit Windows 7 Pro SP1. Auf dem Server ist das Programm mit dem gearbeitet wird (wen es interessiert: ChremaSoft/WinDent) auf dem root installiert (C:\CMS) und im Netzwerk in der Domäne Freigegeben. Der Server dient auch gleichzeitig als Workstation. In der Theorie wird das Programm nun auf allen angemeldeten Workstations über die Freigabe gestartet und damit gearbeitet (Lese und Schreibzugriff regelt das Programm automatisch). In der Praxis funktionierte dies auch bis letzten Freitag (28.02.). Aber seit heute morgen (03.03.) lässt sich das Programm nur noch auf einer Workstation gleichzeitig öffnen. An der Konfiguration hat sich seitdem nichts geändert. Startet man das Programm auf Client A, lässt sich es auf Client B nicht mehr starten (es dauert lange, Client B versucht es auszuführen, aber schlussendlich passiert nichts). Sobald man nun das Programm auf Client A schließt, startet es sofort in gewohnter Manier auf Client B. Sobald das Programm auf einer Workstation ausgeführt wird, ist es in irgendeiner Art und Weise für andere Clients blockiert. Besonderheit hier: Auf dem Server kann das Programm immernoch gleichzeitig mit einer anderen Workstations betrieben werden und funktioniert einwandfrei. Das erkläre ich mir aber so: Auf dem Server wird das Programm direkt von der Festplatte gestartet (C:\CMS\...exe) und auf den Workstations wird es über die Netzwerkfreigabe gestartet (Z:\...exe bzw. \\Server\CMS\...exe). An den Berechtigungen liegt es meines Erachtens nicht: Alle Workstation Benutzer sind Mitglieder der Administratoren-Gruppe und alle Freigaben gewähren jedem Nutzer Vollzugriff. Die Domain Policy: Alles deaktiviert bzw. "Nicht definiert" in den Sicherheitseinstellungen, was nur möglich war. Der DNS mit IP und Name ist in den Interneteinstellungen als Vertrauenswürdige Site eingetragen, damit das Programm überhaupt ausgeführt wird und Server und Workstations haben statische IP's, natürlich mit dem Server als Gateway/DNS. Ich kann mir nicht erklären, warum dieses Verhalten auf einmal auftritt, denn vorher hat es funktioniert und bis auf das Datum hat sich nichts geändert. Ein ähnliches Problem ist hier beschrieben, jedoch gelangte man hier zu keiner Lösung. Gruß