Anwendung von Win2k3 Server auf XP Client zur Verfügung stellen

Anwendung von Win2k3 Server auf XP Client zur Verfügung stellen (60 Beiträge, 387 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Bräuchte wieder mal eure Hilfe. Folgende Problemstellung:

Auf einem Server (Win2003) ist eine Buchhaltungssoftware installiert. Ca. 10 km entfernt gibt es eine Filiale, die mit dieser Software arbeiten muss, ohne dass das Programm Clientseitig installiert werden soll.

Wie stelle ich es nun an, dass sich die Clients zwar zum Server verbinden und die Buchhaltungssoftware ausführen können, ohne jedoch weiteren Zugriff zum Server zu bekommen? Es gibt keine Domäne und kein AD.
Weiters sollen die Mitarbeiter der Filiale über das Buchhaltungsprogramm etwas ausdrucken können. Der Drucker ist in der Filiale lokal installiert.

Bis jetzt ist mir in den Sinn gekommen:
VPN Verbindung einrichten, um mal ins selbe Netz zu kommen. Den lokalen Drucker freigeben und Serverseitig installieren. Dann über TeamViewer (ist bereits vorhanden) den Remotezugriff abwickeln.

Problem: Die Benutzer haben nicht nur auf die Buchhaltungssoftware, sondern auf den ganzen Server Zugriff.

Wie kann ich das geschickter lösen? Am Besten wär's, wenn die Benutzer wirklich nur die Buchhaltungssoftware zu sehen bekommen, sonst nichts!
SPECIAL THANKS TO:
playaz | Spedi

Das Benutzerkonto am Server entsprechend einschränken geht nicht?

Problem: Server muss mit dem Administrator eingeloggt bleiben, da sich ansonsten die SQL-Datenbank schließt. Wenn sich wer mit niedrigeren Rechten einloggt, ist die SQL futsch...
SPECIAL THANKS TO:
playaz | Spedi

Kann der nicht als Service/Dienst gestartet werden?

Nö. Gehört zum Buchhaltungsprogramm, welches ein EINZIGER Pfusch ist. Hab noch nie ein teureres Mistprogramm gesehen. 3,5k Euro + weitere 500 pro Benutzerlizenz. Und Funktionen, die man mit MS Office und einer gut durchdachten Ordnerstruktur auch hat.
SPECIAL THANKS TO:
playaz | Spedi

dann schau dir mal IGS an ^^

wenn ein pc abstürtzt, kannst nachher bei der hotline anrufen damit er sich wieder einloggn kann, weil der ibm server das ned alleine checkt
------
nächster Gottesdienst:
17.06.2009 Die Ärzte@Hamburg (just4DÄOF-Mitglieder)
03.07.2009 Die Ärzte@Linz
04.07.2009 Die Ärzte@Linz
Es gibt nur einen Gott - BelaFarinRod

Ich glaub ich entwickle jetzt auch ein Dokumentenverwaltungsprogramm für Nischenmärkte. Das mit dem ich mich hier rumärgere ist auf Glasereien spezialisiert...anscheinend lasst sich hier noch mächtig Geld scheffeln!
SPECIAL THANKS TO:
playaz | Spedi

Welchen SQL-Server? Dringend umstellen auf Service, oder anderen SQl-Server nehmen.

Save the Earth... it's the only planet with chocolate.

Wer ist eigentlich dieser Ed Hardy?
...und warum kotzt er auf T-Shirts?

Da hab ich keine Macht drüber, wennst bei dem Programm nur das Kleinste umstellst, pfunziwunzifunztatatut nix mehr. Schon selbst ausprobiert. Ich werd aber nochmal sicherstellen, ob es nicht vielleicht doch als Service mitläuft...
SPECIAL THANKS TO:
playaz | Spedi

Kann die Exe über ein Share aufgerufen werden? oder muss das Programm installiert werden am Rechner?

Weil dann kannst einfach den Programmordner freigeben und auf den PCs per Netzlaufwerk verbinden und denen ne Verknüpfung zum Programm am Desktop legen.

Weil dann kannst einfach den Programmordner freigeben und auf den PCs per
Netzlaufwerk verbinden und denen ne Verknüpfung zum Programm am Desktop legen.

Daran hätte ich auch als Erstes gedacht. Nur leider..."de Technik is a Hund".

SPECIAL THANKS TO:
playaz | Spedi

Dann bleibt dir wohl nix über als den User der sich am Server anmeldet zu beschränken was er darf.

Wie kann ich das machen, ohne den Administrator abmelden zu müssen?
SPECIAL THANKS TO:
playaz | Spedi

Was is das fürn Server?

Du könntest zb den Admin lokal anmelden (also per /console (über RDP) oder normal mit der Tastatur/Maus) und die anderen Benutzer dann einfach per Remote Desktop anmelden lassen (2 verbindungen sind erlaubt pro Windows 2003 Server) dann rennt der Admin im Console mode und die Benutzer sind halt mit User1 oder wie auch immer eingeloggt.

Thx, das wusste ich nicht. Sprich, wenn der Admin eingeloggt ist, und es meldet sich der Benutzer "USER" über RDP an, bleibt der Admin trotzdem eingeloggt?
SPECIAL THANKS TO:
playaz | Spedi

Bei nem Server 2003 - oder höher - ja, bei XP kann sich max 1 Benutzer einloggen.

Du musst nur den Benutzer richtig konfigurieren das er sich anmelden kann - Standardmäßig könnens nur Admins und Leute in der Remote Administratoren Liste.

Und natürlich kannst du den User der sich anmeldet einschränken was er machen kann und was nicht.

Eine VPN-Verbindung ist mal eine gute Anfang.

Dann am Server nur das Verzeichnis/die Verzeichnisse wo das Buchhaltungsprogramm liegt, freigeben. Netzwerkshares und NTFS-Shares. Dann kann der User nur dieses Verzeichnis sehen, und damit arbeiten.
Drucker kann lokal angebunden sein, weil die Druckdaten nicht 2x über der gleiche Leitung gehen sollen...

Save the Earth... it's the only planet with chocolate.

Wer ist eigentlich dieser Ed Hardy?
...und warum kotzt er auf T-Shirts?

Das Programm kann über Shares leider nicht ausgeführt werden.

SPECIAL THANKS TO:
playaz | Spedi

Also: das Programm selbst ist nicht Netzwerkfähig, und der darunterliegenden SQL-DB auch nicht. Dafür muss man als Admin sich anmelden damit das Ganze funktioniert...

Lösung: Zu Chef gehen, und ihm sagen das entweder ein Netzwerkfähige Version beim Programmhersteller geordert werden soll, ein anderes (netzwerkfähiges System) gesucht werden soll oder der Server offen ist für jede User.

Ein Möglichkeit gibt es noch: eine virtuelle Maschine aufsetzen (oder echte Maschine), der _nur_ Buchhaltung spielt, und dann per RDP ("mstsc /v:server") dort arbeiten lassen.

Save the Earth... it's the only planet with chocolate.

Wer ist eigentlich dieser Ed Hardy?
...und warum kotzt er auf T-Shirts?

das Programm selbst ist nicht Netzwerkfähig, und der darunterliegenden SQL-DB
auch nicht. Dafür muss man als Admin sich anmelden damit das Ganze
funktioniert...

Fast. Es gibt ein Client-Programm fürs Netzwerk. Allerdings kann das in der angesprochenen Filiale aus unerfindlichen Gründen nicht installiert werden. Der Hersteller schweigt sich zu dem Problem aus. Es gibt faktisch KEINEN techn. Support.

Ich selbst kenne die Anwendung auch so gut wie 0. Bin kein MA der Firma, wurde nur beauftragt, im Netzwerk mal aufzuräumen, da die vorher fürs NW zuständige Firma NUR gepfuscht hat und totale Unordnung hinterlassen hat. Natürlich ohne jegliche Dokumentation (Verkabelung, Passwörter, etc.)
Wir mussten alle Leitungen neu durchtesten und beschriften.

Auf den Router haben wir nach wie vor keinen Zugriff (Fortigate Gateway). Resetten geht nicht, da Maschinen am Netz hängen und es keinen Ausfall geben darf!

SPECIAL THANKS TO:
playaz | Spedi

Es gibt ein Client-Programm fürs Netzwerk. Allerdings kann das in der angesprochenen Filiale aus unerfindlichen Gründen nicht installiert werden.

Lese ich hier heraus das der Client in andere Filialen funktioniert? Wenn ja, würde ich mal schauen welche Ports verwendet werden vom Client, ob die nicht irgendwo gesperrt werden, und vielleicht kannst du mit Wireshark was rausfinden...

Save the Earth... it's the only planet with chocolate.

Wer ist eigentlich dieser Ed Hardy?
...und warum kotzt er auf T-Shirts?

Wenn ja, würde ich mal schauen welche Ports verwendet werden vom Client, ob
die nicht irgendwo gesperrt werden

Wenn ich zum Router Zugriff hätte...aber zur Not muss ich ihn mir sowieso mit einem Reset beschaffen.

Wireshark

Jep, aber ich hätte halt gehofft dass es hier noch einen Geheimtipp gibt...
SPECIAL THANKS TO:
playaz | Spedi

Wenn ich zum Router Zugriff hätte

Einen Hub zwischen Client und Router hängen: dort kannst du schön mitsniffen. Sonst ein Managed Switch besorgen und ein Monitoring-Port einrichten, dann kannst auch sniffen.

Auf http://www.PortableApps.com gibt es ein Wireshark-version, der erst beim Starten der pcap-Treiber installiert, und sich danach restlos wieder entfernt. Damit kannst du am Client mal mitsniffen.

Save the Earth... it's the only planet with chocolate.

Wer ist eigentlich dieser Ed Hardy?
...und warum kotzt er auf T-Shirts?

Ich kann sniffen, aber das verrät mir noch immer nicht das Passwort, das ja (hoffentlich) verschlüsselt übertragen wird!?

Und ich will mich nicht auch noch mit Cain und Rainbowtables rumspielen...
SPECIAL THANKS TO:
playaz | Spedi

Welches PW meinst du jetzt? Das PW vom Router ist (vorerst) ziemlich egal. Solange die sonstige Daten drüber gehen.
Wenn der Client ein PW braucht, dann am Server schauen ob man das irgendwo ändern kann.

Was ich meinte, war ein Sniffen auf ein Client wo es funktioniert, danch auf den Client wo es nicht geht. Vielleicht kannst du sehen wo es hängen bleibt, wann der Kommunikation Clinet-Server abgebrochen wird. Vielleicht ist es wirklich nur ein Router-Einstellung, dann erst musst du dort suchen...

Save the Earth... it's the only planet with chocolate.

Wer ist eigentlich dieser Ed Hardy?
...und warum kotzt er auf T-Shirts?

Was ich meinte, war ein Sniffen auf ein Client wo es funktioniert, danch auf
den Client wo es nicht geht. Vielleicht kannst du sehen wo es hängen bleibt,
wann der Kommunikation Clinet-Server abgebrochen wird. Vielleicht ist es
wirklich nur ein Router-Einstellung, dann erst musst du dort suchen...

Stimmt, so könnte ich den Fehler mal identifizieren!
Aber der Tip von Glockman ist gut, einfach ne RDP einzurichten und beim Aufruf der Verbindung das Programm ausführen zu lassen. Somit sehen die User nur das Programmfenster (laut Glockman). Den lokalen Drucker kann man ja in die RDP mitnehmen...
SPECIAL THANKS TO:
playaz | Spedi

Hi!

Wie viele User müssen gleichzeitig mit der Software arbeiten?
Für bis zu 2 gleichzeitig würde es über RDP so funktionieren:
- Remotezugriff am Server einschalten
- RDP Protokoll konfigurieren (tscc.msc)
- User am Server anlegen
- RDP File am Client kreieren und dort zusätzlich das Programm, das gestartet werden soll, angeben

Damit lässt Du zwar eine Verbindung zum Server zu, beschränkst den Zugriff aber auf dieses eine Programm; sofern man aus dem nicht ausbrechen kann ist der Server sonst "sicher".
Das RDP File kannst Du ja schreibschützen, damit die User nicht versehentlich was verstellen können.
Den Drucker würde ich nicht freigeben und am Server installieren sondern einfach den Clientdrucker in die Session mitnehmen (bietet RDP an, ebenso wie die Zwischenablage).

hth,

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Wie viele User müssen gleichzeitig mit der Software arbeiten?

Am Server nur einer. Alle anderen haben Client-Software installiert.
Super Tip, damit hab ich auch schon geliebäugelt. Nur hätte ich's gern wirklich so gehabt, dass NUR das eine Programm läuft, wenn möglich ohne RDP. Nachdem das aber nicht möglich sein wird, werd ich's auf diese Art wohl zu lösen versuchen!
SPECIAL THANKS TO:
playaz | Spedi

Nur hätte ich's gern wirklich so gehabt, dass NUR das eine Programm läuft, wenn möglich ohne RDP

Mit dieser Methode geht auch nur das Programm in einem Fenster auf - der User sieht weder Desktop noch Startmenü

Ohne RDP bliebe wirklich nur eine Art Remote Control Software, aber damit kommt man immer auf die Konsole - eher suboptimal.

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Mit dieser Methode geht auch nur das Programm in einem Fenster auf - der User
sieht weder Desktop noch Startmenü

Echt? Hab ich nicht gewusst - weil ich's auch noch nie gebraucht habe. Wenn es so ist - natürlich ideal! Dann bräuchte ich theoretisch nicht mal ne VPN Verbindung. Sollte ich den Router noch in meine Gewalt bringen, reicht doch ne Portweiterleitung von Port 1723 auf den Server und kann die RDP mittels DynDNS starten (die haben ne dynamische IP afaik).
SPECIAL THANKS TO:
playaz | Spedi

Echt? [...] Wenn es so ist - natürlich ideal!

Natürlich, sonst hätte ich es doch nicht vorgeschlagen

Dann bräuchte ich theoretisch nicht mal ne VPN Verbindung. Sollte ich den Router noch in meine Gewalt bringen, reicht doch ne Portweiterleitung von Port 1723 auf den Server und kann die RDP mittels DynDNS starten (die haben ne dynamische IP afaik).

Und hier muss ich nochmal nachfragen...

- Portweiterleitung von Port 1723 auf den Server
RDP hat als Zielport 3389 - von welchem Port aus die Verbindung initiiert wird ist aber niemals fix, das OS macht die Ports ja dynamisch auf.

- die RDP mittels DynDNS starten (die haben ne dynamische IP afaik)
Solltest Du gemeint haben, dass das Remote Office eine dynamische IP hat, dann wird das für die Firewall, hinter der der Server hoffentlich steht, wahrscheinlich ein Problem; jede vernünftige FW geht nur auf fixe IP Adressen los, nicht auf Hostnamen. Also würde ich in jedem Fall beim VPN bleiben.

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

- Portweiterleitung von Port 1723 auf den Server
RDP hat als Zielport 3389

RDP hat 3389 und VPN hat 1723. Wenn ich die in der Firewall nicht auf die Server-IP weiterleite, gehts nicht.

Solltest Du gemeint haben, dass das Remote Office eine dynamische IP hat

Nein, die Internet-IP ist dynamisch. Und dafür gibt's DynDNS, um nicht immer nachfragen zu müssen, welche öffentliche IP denn gerade zugewiesen ist. Und die brauch' ich ja schließlich für die VPN-Verbindung...
SPECIAL THANKS TO:
playaz | Spedi

RDP hat 3389 und VPN hat 1723. Wenn ich die in der Firewall nicht auf die Server-IP weiterleite, gehts nicht.

OK, das ist etwas Anderes; nachdem ich aber Dein Setup nicht kenne hat es mich nur gewundert...

Nein, die Internet-IP ist dynamisch.

Also die IP-Adresse, "mit der das Office daherkommt"

Ich sehe das vielleicht ein wenig anders als Du, aber grundsätzlich dürften wir das Selbe meinen.
Und auch hier gilt wieder: ohne das Setup zu kennen kann ich nicht viel mehr sagen als "Es gibt Systeme, die NUR mit fixen IP Adressen arbeiten können". Ob Deine Lösung dazugehört weiß ich leider nicht...

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Also die IP-Adresse, "mit der das Office daherkommt"

Mein Office kommt von der Installations-CD. Die hat keine IP!

Ich meine die IP-Adresse, die die Firma vom ISP zugewiesen bekommt. Der da wäre Telekom Austria.

SPECIAL THANKS TO:
playaz | Spedi

Mein Office kommt von der Installations-CD. Die hat keine IP!

Also meine haben IMMER 127.0.0.1

Da haben wir dann ein wenig aneinander vorbeigedacht; da wo der Server steht ist für mich "Firma" und da wo der eine Anwender arbeiten soll (10km entfernt) ist "Office".

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Da haben wir dann ein wenig aneinander vorbeigedacht; da wo der Server steht
ist für mich "Firma" und da wo der eine Anwender arbeiten soll (10km entfernt)
ist "Office".

Bei mir is da wo der Server steht "Firma". Und da arbeiten auch die Anwender. 10km entfernt ist es die "Filiale", wo ebenfalls Anwender arbeiten!

SPECIAL THANKS TO:
playaz | Spedi

Na dann passt es eh; ersetze einfach mein "Office" mit "Filiale", dann sind wir wieder einer Meinung

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Mit dieser Methode geht auch nur das Programm in einem Fenster auf - der User
sieht weder Desktop noch Startmenü

Hm, hab das grad Testweise mal versucht (zu meinem Heimrechner über eine VPN). Verbindung bekomme ich, aber es startet kein Programm. Muss ich da auf etwas achten?
SPECIAL THANKS TO:
playaz | Spedi

Grundsätzlich nicht; allerdings muss unter Umständen ein Arbeitsverzeichnis angegeben werden. Wird aber auch per Fehlermeldung gemeldet, wenn was nicht passt.

Teste mal mit "C:\Windows\notepad.exe" bei Programm und "C:\Windows" bei Arbeitsverzeichnis als Parameter - da sollte dann nur ein weißes Notepad aufgehen sonst nix.

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Hm. Geht nicht. Ich komm zum Anmeldefenster. Liegt's vielleicht daran, dass ich mich von XP zu XP verbinde? Vielleicht kann das nur der Server?
SPECIAL THANKS TO:
playaz | Spedi

Liegt's vielleicht daran, dass ich mich von XP zu XP verbinde? Vielleicht kann das nur der Server?

Liegt an XP <-> XP, für Server gilt diese Einschränkung nicht.

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Paaast, riesen danke!

SPECIAL THANKS TO:
playaz | Spedi

Gerne, kein Problem

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Habs grad so probiert wie du beschrieben hast. Alles super, nur leider kann ich nur 1 Remotedesktopsitzung starten. (Es müssen doch 2 gleichzeitig am Server arbeiten können.)
Bei einer 2. Verbindung (mit einem 2. Benutzernamen) schreibt er immer, dass die maximale Anzahl an Terminalverbindungen erreicht ist.
tscc.msc ist aber richtig konfiguriert, auf 2 gleichzeitige Verbindungen! Was soll ich jetzt thunfisch?
SPECIAL THANKS TO:
playaz | Spedi

Das Problem ist, dass Windows immer nur 2 RDP Sitzungen (+1 Anmledung an der Konsole) zulässt, und zwar für "administrative Tätigkeiten".
Alles darüber ist eigentlich ein Terminal Server und damit separat zu lizensieren (außerdem muss der Terminal Server als Funktion auch noch installiert sein).
Unter Umständen funktioniert es, wenn Du beide User in die Gruppe der Administratoren am Server reingibst - viel können die dann nicht anstellen, weil ja außer dem Programm nichts erreichbar ist.

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Das Problem ist, dass Windows immer nur 2 RDP Sitzungen (+1 Anmledung an der
Konsole) zulässt, und zwar für "administrative Tätigkeiten".

Mehr brauch ich ja nicht. 2 Anmeldungen. Auf der Konsole ist der Admin ausgeloggt. Also würde ich nur 2 simultane RDP Sitzungen benötigen. pfunziwunzifunztatatut aber ned.

Benutzer sind schon Admins und nat. Remotedesktopbenutzer...
SPECIAL THANKS TO:
playaz | Spedi

Vielleicht stimmt da noch was mit den Sicherheitseinstellungen des RDP Protokolls nicht; in der MSKB findet sich ein Artikel, wie man den Zugriff auf nur eine RDP Sitzung beschränkt (http://support.microsoft.com/kb/830581 ), vielleicht kannst Du ja so herausfinden, ob bei Dir irrtümlich diese bzw. restriktivere Einstellungen gesetzt sind.

Zum Vergleich auch noch schnell die Einstellungen eines "Standardservers":
Administratoren: Full Control
Local Service: Special (Query Information, Send Message)
Network Service: Special (Query Information, Send Message)
Remote Desktop Users: User Access, Guest Access
System: Full Control

Sonst ist in der Liste nichts.

hth,

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Danke, aber es hat dann eh funktioniert. Ich war vorher zu administrativen Zwecken selbst noch eingeloggt (über RDP). Als ich mich abgemeldet hatte, dürfte sich meine RDP Sitzung am Server aufgehängt haben. Ein weiterer Benutzer konnte sich noch anmelden, ein zweiter dann nicht mehr, weil eben meine Sitzung noch offen war. Nach einem Server-Reboot hats jetzt funktioniert!

SPECIAL THANKS TO:
playaz | Spedi

Na wunderbar

2 Tipps noch:
- wenn Du als Admin am Server arbeiten musst, verwende den "/console"-Switch beim Aufruf von mstsc; damit verbindest Du Dich nicht in eine Session sondern eben an die Konsole. Du nimmst so niemandem die Session weg und hast auch kein Problem, wenn schon 2 Sessions offen sind.

- zum Verwalten von Sessions kannst Du tsadmin verwenden, also falls sich eine Session verhängt kann man die damit resetten, ohne den Server neu starten zu müssen. Über tsadmin kannst Du auch in eine Usersession einsteigen, falls nötig.

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Danke für die Tips, wirklich hilfreich!

Ein neues Problem hat sich aufgetan: Gestern habe ich über tsadmin alle RDP-Sitzungen geschlossen. Daraufhin konnten sich die 2 Benutzer simultan anmelden und alles war gut. Zu Mittag meldete sich dann ein Benutzer ab, d.h. er schloss die RDP-Verbindung.
Am Nachmittag wollte er wieder verbinden, jedoch kam die schöne Meldung, dass die "maximale Anzahl der Terminalverbindungen überschritten" sei.

Heute früh wollten sie sich wieder anmelden, und jetzt kommt gar keiner mehr rein. Habe gerade unter tsadmin nachgesehen. Das Problem: Der Server schließt die RDP Sitzungen nicht, sondern lasst sie offen mit der Meldung "getrennt". Das ganze mit einer ID.

Will sich nun ein (derselbe) Benutzer wieder anmelden, gehts nicht, weil die maximale Anzahl überschritten ist. Es wird nicht die bereits bestehende Verbindung geöffnet, sondern eine Neue. Die alten Verbindungen bleiben im System, und somit kann sich keiner mehr einloggen.

Gibt's da ne Lösung dazu, dass der Server immer eine bestehende RDP-Sitzung verwendet?

EDIT: Oder dass er getrennte Verbindungen automatisch sofort löscht?

EDIT2: Habe in der TS-Konfiguration folgendes eingestellt:

Gehe ich richtig in der Annahme, dass nun getrennte Sitzungen nach 1 Minute automatisch gelöscht werden, und sich so beide Benutzer auch nach einer Trennung wieder verbinden können, ohne die maximale Anzahl an Verbindungen zu überschreiten (nach einer Wartezeit von 1 Minute natürlich)?
SPECIAL THANKS TO:
playaz | Spedi

30.04.2009, 09:37 Uhr - Editiert von PhantomLord, alte Version: hier

Gehe ich richtig in der Annahme, dass nun getrennte Sitzungen nach 1 Minute automatisch gelöscht werden, und sich so beide Benutzer auch nach einer Trennung wieder verbinden können, ohne die maximale Anzahl an Verbindungen zu überschreiten (nach einer Wartezeit von 1 Minute natürlich)?

Ja, genau so ist das zu verstehen; wobei das unter Umstäden zu Datenverlust führt, weil dann die Session wirklich ohne Rückfrage beendet wird und was nicht gespeichert ist geht verloren.
Also dem User einfach einbläuen "NICHT nur das Fenster schließen sondern aus dem Programm wirklich aussteigen", dann sollte das Problem auch nicht auftreten.
Damit auch wirklich sichergestellt ist, dass die User abgemeldet werden und sich trotz korrekten Verhaltens des Users die Session nicht "aufhängt" bzw. die Abmneldung ganz klappt gibt es von MS ein Tool, das helfen kann:
UPHClean
http://www.microsoft.com/downloads/details.aspx?FamilyId=1B286E6D-8912-4E18-B570-42470E2F3582&displaylang=en

Das installierst Du am Server, maximal kann es helfen, im schlimmsten Fall tut es aber auch nicht weh, wenn es nicht benötigt wird.

Ich würde aber das Intervall auf 10 oder 15 Minuten raufsetzen, kann ja sein, dass die Verbindung abbricht und der User nicht wirklich absichtlich die Session getrennt hat.
Es sollte aber dann - in diesem Fall innerhalb von diesen 10 bis 15 Minuten - die Session wiederaugenommen werden.

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Super, nochmal danke für die Hilfe! Jetzt dürfte das Problem endgültig aus der Welt geschaffen sein!

SPECIAL THANKS TO:
playaz | Spedi

Das hoffe ich schwer, langsam gehen mir nämlich schon die Ideen für die Lösung eventueller weiterer Probleme aus

greetz

glockman

- There's no replacement for displacement. Not even Diesel. -

vs.

Keine Sorgen, und mir gehen die Ideen für das Erfinden neuer Probleme auch langsam aus!

SPECIAL THANKS TO:
playaz | Spedi

Alle FiBu-Programme (netzwerkfähige), die ich kenne, setzen clientseitig mindestens die Installation eines Frontends voraus. Was du beschreibst, ist mehr oder weniger der Versuch, eine zusätzliche Clientlizensierung zu umgehen. Abgesehen vom sehr wackligen Lizenzrechtsstatus kann die SW gegen genau sowas abgesichert sein.
Und bitte, grad bei Buchhaltungs-SW würde ich nichts pfuschen.
--
Smoking kills. If you're killed, you've lost a very important part of your life.
(Brooke Shields)

In diesem Falle ist es mit dem Hersteller abgesprochen und es wird so toleriert. Es hat auch schon funktioniert, allerdings hat die Firma, die das Netzwerk vorher verwaltet hat, nur Chaos hinterlassen. Und wir müssen jetzt alle Settings selbst neu rausfinden.

SPECIAL THANKS TO:
playaz | Spedi

Aber genau für solche Fälle gibts doch (bei Buchhaltungs-SW) einen Herstellersupport.
--
Smoking kills. If you're killed, you've lost a very important part of your life.
(Brooke Shields)

Bei diesem Hersteller eben nicht. Bzw. ist der Support total unfähig. So eine Tussi, die nicht mal gewusst hat, dass ihre Sofware auf einer SQL-Datenbank lauft...
SPECIAL THANKS TO:
playaz | Spedi

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung