Hat schon einmal jemand die Domänenverwaltung auf einem Server zurück in eine Arbeitsplatzverwaltung durchgeführt?
Hat schon einmal jemand die Domänenverwaltung auf einem Server zurück in eine Arbeitsplatzverwaltung durchgeführt?
Zitat von Jörg Sprenger, Kirchner, Müller am 15. Mai 2026, 12:46 UhrZitat von bro am 14. Mai 2026, 16:26 Uhr
Ist es denn grundsätzlich möglich, einzelne Clients aus der Domän/Domain-Verwaltung zu nehmen und dann als Arbeitsplatzrechner im LAN für MO zu verwenden? Ja. Die Clients arbeiten dann in einer Arbeitsgruppe, so mache ich das, statt in einer Windows-Domäne, dafür muss aber ein Rechner der Boss sein, der Workgroup Server, oder wie man das nennt. Oder ein Server mit Windows Server Betriebssystem, wenn man das hat.
sysdm.cpl – Reiter „Computername“ – Von „Domäne“ auf „Arbeitsgruppe“ umstellen – Neustart – Computerverwaltung → Lokale Benutzer und Gruppen → Benutzer → Neuer Benutzer z.B. LABOR fertig
Wir haben schon immer (auf Grund der Menge der zu verwaltenden Rechner) Server mit Server OS (Windows Server), alles lief aber bis vor 4 Jahren als Arbeitsgruppe. Damit kam ich klar.
Jetzt zur Umstellung Firebird>MariaDB und DBFA vor 3 Jahren, oder waren es 4??, wurde die Domäne eingerichtet, und ich verstehe die Prinzipien dabei nicht, deshalb die Idee der Rückkehr.
Zitat von Julian Hartig am 15. Mai 2026, 9:12 UhrIch muss ehrlich sagen, dass z.B. aufgrund der IT-Sicherheitsrichtlinie am Betrieb einer Domäne eigentlich kein Weg vorbeiführt.
Ja, vermutlich, (siehe oben, ich verstehe es nicht genug) haben sie Recht, aber in den bald 25 Jahren musste ich tausende Male irgendetwas im IT-Sektor der Praxis schnell selber lösen, das konnte ich meistens, komme mir aber zunehmend blöder, nicht erfahrener vor, weil immer mehr Restriktionen verschiedene externe Dienstleister notwendig machen, was bei Problemen dann auch den Kern, die eigentliche medizinische Arbeit behindert, denn externe Dienstleister reagieren, anders als ich, nicht spontan sofort, von den Kosten rede ich da erst einmal gar nicht.
Dadurch, dass mein direkter konkreter Ansprechpartner(FLS) den Betrieb eingestellt hat, wird es nicht leichter.
Zitat von bro am 14. Mai 2026, 16:26 Uhr
Ist es denn grundsätzlich möglich, einzelne Clients aus der Domän/Domain-Verwaltung zu nehmen und dann als Arbeitsplatzrechner im LAN für MO zu verwenden? Ja. Die Clients arbeiten dann in einer Arbeitsgruppe, so mache ich das, statt in einer Windows-Domäne, dafür muss aber ein Rechner der Boss sein, der Workgroup Server, oder wie man das nennt. Oder ein Server mit Windows Server Betriebssystem, wenn man das hat.
sysdm.cpl – Reiter „Computername“ – Von „Domäne“ auf „Arbeitsgruppe“ umstellen – Neustart – Computerverwaltung → Lokale Benutzer und Gruppen → Benutzer → Neuer Benutzer z.B. LABOR fertig
Wir haben schon immer (auf Grund der Menge der zu verwaltenden Rechner) Server mit Server OS (Windows Server), alles lief aber bis vor 4 Jahren als Arbeitsgruppe. Damit kam ich klar.
Jetzt zur Umstellung Firebird>MariaDB und DBFA vor 3 Jahren, oder waren es 4??, wurde die Domäne eingerichtet, und ich verstehe die Prinzipien dabei nicht, deshalb die Idee der Rückkehr.
Zitat von Julian Hartig am 15. Mai 2026, 9:12 UhrIch muss ehrlich sagen, dass z.B. aufgrund der IT-Sicherheitsrichtlinie am Betrieb einer Domäne eigentlich kein Weg vorbeiführt.
Ja, vermutlich, (siehe oben, ich verstehe es nicht genug) haben sie Recht, aber in den bald 25 Jahren musste ich tausende Male irgendetwas im IT-Sektor der Praxis schnell selber lösen, das konnte ich meistens, komme mir aber zunehmend blöder, nicht erfahrener vor, weil immer mehr Restriktionen verschiedene externe Dienstleister notwendig machen, was bei Problemen dann auch den Kern, die eigentliche medizinische Arbeit behindert, denn externe Dienstleister reagieren, anders als ich, nicht spontan sofort, von den Kosten rede ich da erst einmal gar nicht.
Dadurch, dass mein direkter konkreter Ansprechpartner(FLS) den Betrieb eingestellt hat, wird es nicht leichter.
Zitat von Jörg Sprenger, Kirchner, Müller am 15. Mai 2026, 12:59 UhrZitat von Johannes Braun am 13. Mai 2026, 22:50 UhrAlso ich finde der Punkt an dem man die Rechner nicht einzeln verwalten möchte kommt relativ schnell – eine Domäne macht vieles einfacher.
Was ist denn das komplizierte daran?Wir haben ~30 PCs es wäre die Hölle, wenn man da auf jedem PC alles einzeln einstellen müsste.
Ein zentrales DNS, Benutzerverwaltung sorgt außerdem dafür, dass man da nicht basteln muss und die Netzwerkfreigabe für z.B. MO einfach funktioniert und man sich nicht auf jedem PC mit einem lokalen Konto vom Server anmelden muss.
Vor der Domäne gab es auf jedem unserer Rechner ein Frickel Batch Skript, welches das Netzlaufwerk verbunden hat … und vorallem die Drucker waren eine Katastrophe auf jedem Rechner anders eingestellt.
Oh, daran ist das komplizierteste, dass der User (ich) es nicht beherrscht 🙂
Es scheint, ich komme nicht drum rum, auch dieses Feld noch zu erlernen.
Zitat von Julian Hartig am 15. Mai 2026, 9:12 UhrWie bro bereits beschrieben hat, kann man einen Rechner jederzeit aus der Domäne lösen. Man braucht dann eben lokale Konten für die Anmeldung. Allerdings ist nach dem Lösen der Domäneneinbindung kein Zugriff mehr auf (vernünftig sicher) konfigurierte Shares der Domäne möglich und damit auch keine MO-Nutzung (da man hierfür auf den Serverinstallationspfad von MO zugreifen können muss, was u.a. für die Clientupdates gebraucht wird).
VG Julian Hartig
Okay, letzteres klingt dann wie ein KO-Kriterium.
Wenn ich mir die Historie vor Augen führe, wie MO hier primär vom FLS installiert wurde, ohne Domäne, mit einer Anmeldung für alle am System, lediglich in MO mit eigenen Konten, dann war das sicherheitstechnisch wie bei der Arbeit mit Karteikarten, alle können alles lesen, kopieren, mitnehmen, aber erlaubt ist es nur dem Praxisinhaber.
Wie Bro sagt, gut geschulte und weiter gebildete Mitarbeiter können auch hier noch alle Daten lesen, Vertrauen ist hier nicht IT-technisch gelöst/verwaltet.
Ich werde mich mit der Domänenverwaltung beschäftigen, dann nähere ich mich meiner Eingangsfrage von der anderen Seite, werde aber sicher nie den IT-Kenntnisstand von Ihnen erreichen, denn wenn ich mich richtig erinnere, kommen Sie aus diesem Bereich, oder?
Zitat von Johannes Braun am 13. Mai 2026, 22:50 UhrAlso ich finde der Punkt an dem man die Rechner nicht einzeln verwalten möchte kommt relativ schnell – eine Domäne macht vieles einfacher.
Was ist denn das komplizierte daran?Wir haben ~30 PCs es wäre die Hölle, wenn man da auf jedem PC alles einzeln einstellen müsste.
Ein zentrales DNS, Benutzerverwaltung sorgt außerdem dafür, dass man da nicht basteln muss und die Netzwerkfreigabe für z.B. MO einfach funktioniert und man sich nicht auf jedem PC mit einem lokalen Konto vom Server anmelden muss.
Vor der Domäne gab es auf jedem unserer Rechner ein Frickel Batch Skript, welches das Netzlaufwerk verbunden hat … und vorallem die Drucker waren eine Katastrophe auf jedem Rechner anders eingestellt.
Oh, daran ist das komplizierteste, dass der User (ich) es nicht beherrscht 🙂
Es scheint, ich komme nicht drum rum, auch dieses Feld noch zu erlernen.
Zitat von Julian Hartig am 15. Mai 2026, 9:12 UhrWie bro bereits beschrieben hat, kann man einen Rechner jederzeit aus der Domäne lösen. Man braucht dann eben lokale Konten für die Anmeldung. Allerdings ist nach dem Lösen der Domäneneinbindung kein Zugriff mehr auf (vernünftig sicher) konfigurierte Shares der Domäne möglich und damit auch keine MO-Nutzung (da man hierfür auf den Serverinstallationspfad von MO zugreifen können muss, was u.a. für die Clientupdates gebraucht wird).
VG Julian Hartig
Okay, letzteres klingt dann wie ein KO-Kriterium.
Wenn ich mir die Historie vor Augen führe, wie MO hier primär vom FLS installiert wurde, ohne Domäne, mit einer Anmeldung für alle am System, lediglich in MO mit eigenen Konten, dann war das sicherheitstechnisch wie bei der Arbeit mit Karteikarten, alle können alles lesen, kopieren, mitnehmen, aber erlaubt ist es nur dem Praxisinhaber.
Wie Bro sagt, gut geschulte und weiter gebildete Mitarbeiter können auch hier noch alle Daten lesen, Vertrauen ist hier nicht IT-technisch gelöst/verwaltet.
Ich werde mich mit der Domänenverwaltung beschäftigen, dann nähere ich mich meiner Eingangsfrage von der anderen Seite, werde aber sicher nie den IT-Kenntnisstand von Ihnen erreichen, denn wenn ich mich richtig erinnere, kommen Sie aus diesem Bereich, oder?
Zitat von Thomas Schössow am 15. Mai 2026, 13:25 UhrZitat von Julian Hartig am 15. Mai 2026, 9:12 UhrIch muss ehrlich sagen, dass z.B. aufgrund der IT-Sicherheitsrichtlinie am Betrieb einer Domäne eigentlich kein Weg vorbeiführt. Es brauchen nämlich alle Mitarbeitenden eigene Benutzerkonten und Passwörter (sonst gibt es Probleme, wenn jemand ausscheidet und es ist auch keine abgestufte Berechtigungsvergabe möglich), und wenn Sie keine Domäne haben, müssen Sie dann auf jedem Rechner die Konten einzeln pflegen. Auch die Rechteverwaltung für Shares ist ohne Domäne faktisch nicht möglich.
Ein klares Nein. Eine Domäne hat keinen positiven Einfluss auf die IT-Sicherheit, im Gegenteil.
Zitat von Julian Hartig am 15. Mai 2026, 9:12 UhrIch muss ehrlich sagen, dass z.B. aufgrund der IT-Sicherheitsrichtlinie am Betrieb einer Domäne eigentlich kein Weg vorbeiführt. Es brauchen nämlich alle Mitarbeitenden eigene Benutzerkonten und Passwörter (sonst gibt es Probleme, wenn jemand ausscheidet und es ist auch keine abgestufte Berechtigungsvergabe möglich), und wenn Sie keine Domäne haben, müssen Sie dann auf jedem Rechner die Konten einzeln pflegen. Auch die Rechteverwaltung für Shares ist ohne Domäne faktisch nicht möglich.
Ein klares Nein. Eine Domäne hat keinen positiven Einfluss auf die IT-Sicherheit, im Gegenteil.
Zitat von bro am 15. Mai 2026, 14:58 UhrVon wie vielen Clients und Server reden wir eigentlich; und viele Systeme wurden „historisch gewachsen“ eingerichtet und kein Mensch weiß mehr genau, welche Dienste noch Domain-Abhängigkeiten haben könnten.
Wir haben schon immer (auf Grund der Menge der zu verwaltenden Rechner) Server mit Server OS (Windows Server), alles lief aber bis vor 4 Jahren als Arbeitsgruppe. = Cleaninstall in Erwägung ziehen, weil man sich ja erst noch einarbeiten muss.egal wen man fragt, das ist der Job.
Phase 1: Freitagabend – Vorbereitung & Freeze
- Praxisbetrieb schließen: Alle Mitarbeiter von den Systemen abmelden.
- Dokumenten-Snapshot: Letzte Kontrollen der IP-Konfigurationen, DNS-Einträge und TI-Routings sichern.
- Voll-Backup (Bare-Metal): Vollständige Sicherung aller Server und des DCs durchführen.
- Hypervisor-Snapshots: VM-Snapshots (inkl. Arbeitsspeicher) aller Server im ausgeschalteten Zustand erstellen.
- Lokale Admin-Konten: Auf allen Clients und verbleibenden Servern das lokale Administrator-Passwort prüfen und dokumentieren.
Phase 2: Samstagvormittag – Daten- & Dienstmigration
- SQL & Medical Office: Datenbanken auf dem neuen Zielserver (oder lokal) wiederherstellen.
- Dienstekonten anpassen: SQL- und Medical-Office-Dienste auf lokale Konten (z. B.
LocalSystemoder dedizierte lokale Admins) umstellen.- Freigaben & NTFS-Rechte: Ordnerfreigaben auf das neue Ziel migrieren. NTFS-Berechtigungen von Domänen-Gruppen auf lokale Gruppen oder „Jeder“ (Sicherheitsrisiko abwägen) anpassen.
- TI-Infrastruktur: Konnektor und eHealth-Terminals prüfen. Routing-Tabellen im Konnektor kontrollieren, falls das Gateway oder der DNS-Server migriert wurden.
Phase 3: Samstagnachmittag – Client-Migration & Profilrettung
- Profil-Migration: Domänen-Clients mit einem Tool (z. B. Profwiz) in lokale Profile konvertieren. Dadurch bleiben Desktops, Praxissoftware-Einstellungen und Zertifikate erhalten.
- DNS-Umstellung an den Clients: DNS-Server in den Netzwerkeinstellungen (oder im DHCP-Server/Router) auf den neuen DNS-Server umbiegen.
- Domänen-Austritt: Clients aus der Domäne entfernen und in eine Arbeitsgruppe (Workgroup) aufnehmen. Neustart durchführen.
Phase 4: Sonntagvormittag – DC-Rückbau & Netzwerkaufräumung
- NTP-Server ändern: Zeitsynchronisation (wichtig für die TI) auf dem Router oder der Firewall einrichten. Clients darauf verweisen.
- Letzter DC-Check: Sicherstellen, dass keine versteckten Abhängigkeiten mehr aktiv sind (Logfiles prüfen).
- Saubere Demotierung: Den Domain Controller über den Server-Manager (
Uninstall-ADDSDomainController) sauber herabstufen. Niemals einfach löschen.- DNS-Bereinigung: Den alten DC-Eintrag aus den verbleibenden DNS-Zonen (falls vorhanden) löschen.
Phase 5: Sonntagnachmittag – Intensiver Funktionstest (Go / No-Go)
- Anmelde-Test: Anmeldung an allen Arbeitsplätzen als lokaler Benutzer prüfen.
- Software-Test: Medical Office starten, Datenbankverbindung prüfen, Patientenkartei aufrufen.
- Kartenleser-Test: eGK stecken und Einlesen in die Praxissoftware testen.
- Peripherie-Test: Drucken (Rezepte, Blanko) und Scannen von allen Arbeitsplätzen testen.
- TI-Test: KV-Safenet-Verbindung und E-Rezept-/eAU-Schnittstellen prüfen.
- Deadline für Rollback (18:00 Uhr): Schlagen essenzielle Tests fehl, wird das Wochenende abgebrochen und die Snapshots von Freitagabend wieder eingespielt.
Phase 6: Montagmorgen – Early Support
- Vor-Ort-Präsenz: Mindestens 1 Stunde vor Praxisöffnung vor Ort sein.
- Echtbetrieb begleiten: Die ersten 3 Patientenaufnahmen und Rezepterstellungen persönlich überwachen.
Von wie vielen Clients und Server reden wir eigentlich; und viele Systeme wurden „historisch gewachsen“ eingerichtet und kein Mensch weiß mehr genau, welche Dienste noch Domain-Abhängigkeiten haben könnten.
Wir haben schon immer (auf Grund der Menge der zu verwaltenden Rechner) Server mit Server OS (Windows Server), alles lief aber bis vor 4 Jahren als Arbeitsgruppe. = Cleaninstall in Erwägung ziehen, weil man sich ja erst noch einarbeiten muss.
egal wen man fragt, das ist der Job.
- Praxisbetrieb schließen: Alle Mitarbeiter von den Systemen abmelden.
- Dokumenten-Snapshot: Letzte Kontrollen der IP-Konfigurationen, DNS-Einträge und TI-Routings sichern.
- Voll-Backup (Bare-Metal): Vollständige Sicherung aller Server und des DCs durchführen.
- Hypervisor-Snapshots: VM-Snapshots (inkl. Arbeitsspeicher) aller Server im ausgeschalteten Zustand erstellen.
- Lokale Admin-Konten: Auf allen Clients und verbleibenden Servern das lokale Administrator-Passwort prüfen und dokumentieren.
- SQL & Medical Office: Datenbanken auf dem neuen Zielserver (oder lokal) wiederherstellen.
- Dienstekonten anpassen: SQL- und Medical-Office-Dienste auf lokale Konten (z. B.
LocalSystemoder dedizierte lokale Admins) umstellen. - Freigaben & NTFS-Rechte: Ordnerfreigaben auf das neue Ziel migrieren. NTFS-Berechtigungen von Domänen-Gruppen auf lokale Gruppen oder „Jeder“ (Sicherheitsrisiko abwägen) anpassen.
- TI-Infrastruktur: Konnektor und eHealth-Terminals prüfen. Routing-Tabellen im Konnektor kontrollieren, falls das Gateway oder der DNS-Server migriert wurden.
- Profil-Migration: Domänen-Clients mit einem Tool (z. B. Profwiz) in lokale Profile konvertieren. Dadurch bleiben Desktops, Praxissoftware-Einstellungen und Zertifikate erhalten.
- DNS-Umstellung an den Clients: DNS-Server in den Netzwerkeinstellungen (oder im DHCP-Server/Router) auf den neuen DNS-Server umbiegen.
- Domänen-Austritt: Clients aus der Domäne entfernen und in eine Arbeitsgruppe (Workgroup) aufnehmen. Neustart durchführen.
- NTP-Server ändern: Zeitsynchronisation (wichtig für die TI) auf dem Router oder der Firewall einrichten. Clients darauf verweisen.
- Letzter DC-Check: Sicherstellen, dass keine versteckten Abhängigkeiten mehr aktiv sind (Logfiles prüfen).
- Saubere Demotierung: Den Domain Controller über den Server-Manager (
Uninstall-ADDSDomainController) sauber herabstufen. Niemals einfach löschen. - DNS-Bereinigung: Den alten DC-Eintrag aus den verbleibenden DNS-Zonen (falls vorhanden) löschen.
- Anmelde-Test: Anmeldung an allen Arbeitsplätzen als lokaler Benutzer prüfen.
- Software-Test: Medical Office starten, Datenbankverbindung prüfen, Patientenkartei aufrufen.
- Kartenleser-Test: eGK stecken und Einlesen in die Praxissoftware testen.
- Peripherie-Test: Drucken (Rezepte, Blanko) und Scannen von allen Arbeitsplätzen testen.
- TI-Test: KV-Safenet-Verbindung und E-Rezept-/eAU-Schnittstellen prüfen.
- Deadline für Rollback (18:00 Uhr): Schlagen essenzielle Tests fehl, wird das Wochenende abgebrochen und die Snapshots von Freitagabend wieder eingespielt.
- Vor-Ort-Präsenz: Mindestens 1 Stunde vor Praxisöffnung vor Ort sein.
- Echtbetrieb begleiten: Die ersten 3 Patientenaufnahmen und Rezepterstellungen persönlich überwachen.
Zitat von Jörg Sprenger, Kirchner, Müller am 18. Mai 2026, 16:29 UhrHallo Bro
Diese schöne Anleitung habe ich mir angepinnt 😀
Eine interessante Beobachtung, wir haben 17 Lizenzen, davon einen Server, einen Backup-Server, 2 weitere Mobile-Clients, von letzteren ist einer in einer anderen Domäne (alles vom FLS so eingerichtet), aber auch dieser funktioniert hier reibungslos incl. der Updates, obwohl er NICHT in der Hauptdomäne angemeldet ist. Schön und unverständlich für mich, aber ich lerne das ja jetzt und kann es sicher demnächst erklären 😄
Hallo Bro
Diese schöne Anleitung habe ich mir angepinnt 😀
Eine interessante Beobachtung, wir haben 17 Lizenzen, davon einen Server, einen Backup-Server, 2 weitere Mobile-Clients, von letzteren ist einer in einer anderen Domäne (alles vom FLS so eingerichtet), aber auch dieser funktioniert hier reibungslos incl. der Updates, obwohl er NICHT in der Hauptdomäne angemeldet ist. Schön und unverständlich für mich, aber ich lerne das ja jetzt und kann es sicher demnächst erklären 😄
Zitat von Thomas Schössow am 18. Mai 2026, 16:58 UhrFür mich persönlich als Abschluss dieser Diskussion: Eine Windows-Domäne hat NICHTS mit der Medical Office Funktionalität zu tun. Ob ein Rechner in einer Domäne ist oder eben nicht, ist MO völlig egal. Wichtig ist ein Share auf die Datenbank des MO-Servers und das die Drucker „irgendwie“ erreicht werden. Domänen sind eine Methode, Rechner und Nutzer unter Windows zu verwalten, nichts Anderes.
Für mich persönlich als Abschluss dieser Diskussion: Eine Windows-Domäne hat NICHTS mit der Medical Office Funktionalität zu tun. Ob ein Rechner in einer Domäne ist oder eben nicht, ist MO völlig egal. Wichtig ist ein Share auf die Datenbank des MO-Servers und das die Drucker „irgendwie“ erreicht werden. Domänen sind eine Methode, Rechner und Nutzer unter Windows zu verwalten, nichts Anderes.
Zitat von bro am 18. Mai 2026, 17:50 UhrDas ist alles ja richtig. Es spricht auch gar nichts gegen eine Domain man muss das aber können, oder lernen. Das war der Punkt. Und so wirklich Arztsache ist das halt nicht. Windows Server ohne Domain (Workgroup) ist halt leichter darstellbar, als Windows Server + Domain.
Das ist alles ja richtig. Es spricht auch gar nichts gegen eine Domain man muss das aber können, oder lernen. Das war der Punkt. Und so wirklich Arztsache ist das halt nicht. Windows Server ohne Domain (Workgroup) ist halt leichter darstellbar, als Windows Server + Domain.