\\. ist auf einem WTS nicht erlaubt ?

d.schmitt

d.schmitt

Sage Partner Moderator
Teammitglied
Hallo,
ich habe bei einem Kunden folgendes Problem OL 8.1:

anscheinend hat irgendein Laptop von einem Mitarbeiter das eine Serverinstallation drauf hatte ein Live Update durchgeführt, dies wurde aber nicht für den lokalen Client gemacht sondern für ALLE , der Server hatte somit den Stand 14.08 und die Clients 13.07.


Es kamen folgende Meldungen auf dem Client und auf dem Server:

clip_image002.jpg

upload_2019-8-27_12-43-3.png

clip_image004.jpg

upload_2019-8-27_12-43-12.png

Auf dem Server habe ich das Live Update dann neu gemacht, hier gab es auch schon Probleme das das LU nicht einfach über ausführen gestartet werden konnte:


clip_image005.jpg



Ich nehme an irgendwas wird / wurde blockiert, ich habe daraufhin das LU aus der Knowledge Base heruntergeladen und ausgeführt, dies lief auch durch.


Leider war der Fehler immer noch da:

clip_image004.jpg

upload_2019-8-27_12-43-31.png

Egal was ich versucht habe / DB aktualiseren / cfg Datei gelöscht / abfapp ausgetauscht etc. hat nicht geholfen. Ich musste erstmal in der KHKUsys Catalog den Wert bei KHKAdressen auf 2 setzen dann ging die Anmeldung.. Aktuell geht auch die Anmeldung auf dem Server!


Auf den Clients kommt noch folgende Meldung:

upload_2019-8-27_12-43-44.png
clip_image002.jpg



Prüfung auf den Client in der cfg und in der Regedit sowie in der Shared Client exe sagen das alle skorrekt gesetzt ist!


Der Kollege aus der IT lässt grad prüfen ob irgendwas an den Zugriffen geändert wurde / Ports / Rechte etc.


Auch eine Neuinstallation macht wohl Fehler laut Kunde , ich habe im Moment keine Idee und versuche schon SAGE zu erreichen.


Habt ihr noch ne Idee ?


Aktueller Stand ist nur Server kann sich anmelden.
 
Ist noch der korrekte Mehrbenutzerdienst-Server ist auf den Clients hinterlegt? Es scheint so, als ob dieser nicht kontaktiert werden kann.

Über <C:\Program Files (x86)\Sage\Sage 100\8.1\Shared\Sagede.OfficeLine.ClientAdmin.exe> kann man dies am Client ja nachsehen und einfach nochmal speichern. Wenn dort ein Fehler angezeigt wird, obwohl der richtige Server eingetragen ist, ist es vielleicht ein Problem mit der Namensauflösung im Netzwerk?
 
Hallo,
ja steht überall das korrekt drin, aktuell prüft der Kunde innerhalb der IT ob was verändert wurde, ich hoffe das dabei was rauskommt. Danke!
 
\\. ist kein gültiger UNC Pfad für den Server auf dem der Mehrbenutzer Dienst läuft.
Beim Rest scheint ein DNS Problem allgemein vorzuliegen.
Client=2 und DB=1 ist ein nicht vollständiges Liveupdate, was auch wieder von dem \\. und fehlerhaften DNS Einstellungen kommt.
LiveUpdate nach Korrektur der Werte noch einmal mit vollständiger Aktualisierung laufen lassen und im Anschluss noch DB Aktualisierung sollte das Problem beheben.
 
Der Auslöser für das Problem scheinen Windows Updates zu sein. Zumindest ist es genau das was bei mir passiert ist.
Alles Funktioniert -> Windows Updates ->
upload_2019-8-27_12-43-3-png.952
 
Tja irgendwie ist aktuell alles ein Auslöser.. im Moment hab ich etwas Angst überhaupt was durchzuführen wie Windows Updates / etc. da ansonsten wieder irgendwelche Fehler seitens SAGE kommen...
 
Wir hatten das Problem gestern auch...
Wir haben an den betroffenen Cleints den Sage PreLoad beendet und kurz gewartet danach ging der Start wieder.

d.schmitt schrieb:
Tja irgendwie ist aktuell alles ein Auslöser.. im Moment hab ich etwas Angst überhaupt was durchzuführen wie Windows Updates / etc. da ansonsten wieder irgendwelche Fehler seitens SAGE kommen...
Zum Vergrößern anklicken....

Ja das Vertrauen in die Sage Entwicklung bzw. deren Bereitschaft rechtzeitig auf Updates / Service Packs etc. Ihre Programme zu prüfen und zu aktualisieren lässt zu wünschen übrig.

Zum Glück gibt es ja keine RC oder BETAS der Windows, SQL etc. Versionen...
 
Hi,
aktuell haben wir das sogar vermehrt intern bei uns.
Als wenn die OL kein Netzwerk hat , was Sie aber hat bzw. der Client.

Echt merkwürdig und Ansatzpunkte sind auch recht schwierig zu ermitteln.
 
Diese Meldung haben wir bei einem Kunden jetzt auch vermehrt. Kam aber aus dem nichts. Auf den betroffenen Clients hilft es im Explorer mal im Pfad \\Servernamen einzugeben, danach kommt die Fehlermeldung nicht mehr und die Anmeldung funktioniert wieder. Von Sage haben wir bisher auch noch keinen richtigen Lösungsvorschlag...
 
ich sehe wir sind nicht alleine mit den Problemen, irgendwie betrifft es immer nur direkt die SAGE Office Line und andere Programme gefühlt nicht. Das sorgt aktuell natürlich für Ärgernis was ich verstehen kann... und wie es aussieht gibt es nicht "einen" Lösungsweg sondern es kann viel sein was das Problem evtl. für einige Zeit behebt. Auch wie zb. mit der manifest Datei von Access die sich ja bei Windows Updates evtl. überschreibt. Aktuell ist die OL nicht so einfach zu supporten...
 
Seit den neuesten Windows Updates und Sage LiveUpdates, haben wir auch diese Probleme. Können wir so bestätigen.
Erst kam die Meldung Mehrbenutzerdienst läuft nicht. War natürlich Quatsch. Auf dem Server den Dienst mehrfach gestartet und gestoppt, es gab keine Probleme und keine Einträge in den Error Logs.
Dann aufgrund des Hinweises hier mal den Weg mit dem Pfad aus Verzweiflung eingeschlagen Pfad\\ServerName und siehe da es gab eine Fehlermeldung die wir aber nicht verstanden haben. Nach dem Neustart war dieser Fehler weg und das LiveUpdate ist durchgelaufen. Starten der Anwendung danach aber nicht möglich. Von angeblich Benutzer nicht registriert, über es kann kein neuer Benutzer mit NT Authentifizierung angelegt werden. Mit einem Bennutzer ohne NT Authentifizierung war dann eine Anmeldung möglich nur gab es dann die bekannten Objektfehler.
Eine Odyssee ohne Ende. Und der Sage Support erst "Wir wissen von nicht." Dann nach dem ich mit ihnen einiges durchgekaut habe "Autsch eventuell doch Probleme" Ticket wurde aufgemacht und an die "Entwicklung weiter gereicht. Mindestens 24 Stunden Wartezeit.
Mal abgesehen von der Zeit die wir investieren in diesen Schr... können einen die Kunden so langsam auch Leid tun. Aber langjährige OL Benutzer scheinen ja abgehärtet zu sein. Ob es die Qualität betrifft oder die Preise.
Ich werde wieder berichten.

Der neueste Fehler wieder dieser, hatten wir auch schon mal, aber wir können doch nicht alles dokumentieren, was da fast täglich anfällt. Vielleicht hat jemand eine Lösung. Das ist der Administrator als Wartungsclient.
upload_2019-9-17_18-12-23.png
Quittieren den Fehler und die Anwendung scheint augenscheinlich zu funktionieren.
Was ist das nur für eine Software. Da müsste man eigentlich noch Geld für bekommen, wenn man so etwas verwendet.
 
@mandreck

Ich bin in da vollkommen bei dir.
Wie ich schon des öfteren geschrieben habe ist die Qualitätsprüfung nicht wirklich gut.
Standardfunktionen funktionieren nicht (Bsp. pdf speichern ohne verschluckte Texte in RTF-Feldern)
Hier schiebt sich wohl Sage und Stimulsoft den Ball gegenseitig zu... anstatt lieber mal gemeinsam an einer Lösung arbeiten.

Selbiges beim DMS.
Eine Volltextsuche wo nicht sauber findet sollte dem Namen DMS erst garnicht verdienen!
Auch hier die langsame Updatepolitik von Sage einfach nicht zu glauben.
(cool ist ja ein Live-Update des DMS welches nie Updates findet...)

Wir sind mittlerweile auch schon an dem Punkt die Sage 100 im Haus endgültig zu ersetzen da es so einfach kein Spaß mehr macht und man so nicht produktiv arbeiten kann.

Wir entwickeln selbst Software und wissen das man nicht alles bis ins kleinste Detail (bzw. jede Konstellation) prüfen kann, aber was hier an Bugs aufkommt sind wirklich teilweise 0815 Sachen die müssten jedem Tester sofort auffallen.

Und wenn man auf offensichtliche Bugs hinweist wird man noch zur Kasse gebeten.

Ich dachte Sage schlägt einen richtigen Weg ein da die Office Line veraltet war. (weil es verschlafen wurde)
Naja wie du auch schon sagst...
"Aber langjährige OL Benutzer scheinen ja abgehärtet zu sein. Ob es die Qualität betrifft oder die Preise."

Die Frage ist immer wann das Fass endgültig überläuft...
 
Hallo Mandrek,

diese Meldung (CallBackHandler) hatte ich auch schon - Fehlerbehebung war beim ersten mal etwas kurios und beim zweiten mal langwierig...

1tes Mal:
Wir haben sämtliche Server und Clientrechner neu gestartet - auf einem Server waren die Windowsupdates "wohl" noch nicht fertig konfiguriert, nach den Neustarts war die Meldung dann weg.

2tes Mal:
Eine zweite Ursache hierfür war mal ein fehlerhaft installiertes Office 2016
Hier wurden dann das Office mit Microsoft-Fix-it komplett deinstalliert, Access RT 2013 neu installiert, Office2010Pia neu installiert, Taskpane2 Keys hinzugefügt in Registry danach liefs dann auch wieder.
 
Hallo,

wir kennen den Fehler Access Call Back Handler wenn Abhängigkeiten fehlen:
zb.:
Native Client
PDF X Change
SQL 2005 Abwärtskompatibilität

Neuerdings fällt uns imme rmehr auf das manchmal Abhängigkeiten gar nicht mit installiert werden, erfolgreichster Kandidat sind die Interop Assamblies!
 
Erst mal danke an alle auch für das Mitgefühl. :(
@Manuel Goldschmidt wir wollten oder müssen einige Kunden übernehmen von einem ehemaligen Business Partner.
Jetzt wird uns langsam auch einiges klarer. Nicht er wurde gekündigt, er hat gekündigt.
Standards laufen nicht, bzw. sind komplett daneben programmiert, ich denke auch die haben in den letzten 20 Jahren an der "Nordwind" DB von MS einfach nur drum herum gebastelt.
Wir hatte auch große Hoffnung auf die Umstellung gesetzt und haben uns erst nach 2 Jahren (Januar 2018) dazu entschieden es wieder mit Sage OL zu versuchen, nach unserem Ausstieg in 2004 mit OL2.1.
Aber unsere Erwartungen nach über 15 Jahren sind komplett enttäuscht worden.
Mal sehen was wir noch daraus machen werden. Momentan schieben wir nur noch Frust.

@Wolverine Windows Updates sind überall aktuell /Neustart selbstverständlich
Verwendet wir von den Kunden in der Regel Office 365 (das heißt automatisch immer die aktuellste Version) sollte für eine Access 2013 Runtime auch keine Rolle spielen, da die Runtime in einem anderen Unterverzeichnis von Office läuft.
Daran kann es nicht liegen. Auch schon die Runtime aus der aktuellen DVD Version noch einmal drüber gebügelt. Problem hat sich nicht geändert.
Taskpane2 Keys sagt mir nichts.

@d.schmitt Der SQL Server ist eine andere physikalische Maschine, der Client stellt nur die DB Verbindung her.
Die ja auch zu funktionieren scheint denn nach dem bestätigen des Access Fehlers, erscheinen ja auch die Vorgänge, Kunden etc. Nur weitere Access Fehler kommen als Folgefehler.

Mal schauen wie das Drama weiter geht.
 
Ich kenne den Fehler auch vermehrt bei unseren Kunden. Es reicht bei mir immer aus, wenn der User den UNC Pfad unter Windows nochmals manuell eingibt, damit der Speicherort für das LiveUpdate gefunden wird. Dann die Sage starten. Woran das liegt weiß ich ebenfalls nicht. Kommt aber nicht ständig vor. Ich hatte auch Windows Updates in Verdacht.
 
Das LiveUpdate läuft ja an den Clients. Auch ohne Fehler durch. Nur danach treten die genannten Fehler auf.
 
Gibt es hier schon Neuigkeiten bezüglich dieser Meldung?
Unsere Clients bekommen diese Meldung quasi jedes mal wenn die Netzwerkverbindung unterbrochen wird. (zb. wenn Windows in den Energiesparmodus geht)
 
Hallo,

wir haben den Fehler jedes Mal wenn der Server neu gestartet wird, während die Client PCs schon an sind. In diesem Fall müssen die Client PCs auch neu gestartet werden und anschließend ist die Fehlermeldung weg. Ich vermute das der lokale Mehrbenutzerdienst die Verbindung zum Server nach einem Serverneustart nicht mehr aufbauen kann (oder so).

Kommt aber Gott sei Dank nicht allzu oft vor das wir den Server untertags neu starten müssen.

Gruß

Dimi
 
@MMueller das ist kein Fehler, das ist so gewollt. Bzw. auch eine Eigenschaft der Windows Authentifizierung.
Energiesparmodus ist eben kein An- und Abmelden und somit wird der Client / Benutzer nicht authentifiziert.
Hier hilft es den Energiesparmodus anzupassen. Abschalten der Festplatten sollte verhindert werden und im Gerätemanager unter Netzwerkverbindungen unter Energieverwaltung nicht erlauben das der Energiesparmodus die Netzwerkadapter deaktivieren kann.

@DimiP auch hier gilt das oben gesagte. Windows Authentifizierung. Ein einfaches Ab- und Anmelden neu sollte hier reichen. Üblicherweise sollten sich die Clients vor einem Server Neustart eigentlich abmelden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben