NilsK

Moin, dafür müsste der Patch ja auch eingespielt worden sein. Darüber wissen wir hier nichts, soweit ich sehe. Gruß, Nils

Moin, dafür müssten wir jetzt sehr weit ausholen, um die Zertifikats-Basics zu diskutieren, fürchte ich. Wäre vielleicht etwas viel für ein Forum. In aller Kürze: statt eine CA einzurichten, erzeugst du auf "irgendeinem" System mit einem lokalen Tool dein Root-Zertifikat. Mit diesem Root-Zertifikat stellst du mit demselben Tool das gewünschte Server-Zertifikat aus. Das Root-Zertifikat importierst du in die "Vertrauenswürdigen Zertifizierungsstellen" auf den beteiligten Systemen. Das Server-Zertifikat bindest du in den Dienst ein, der es nutzen soll. Da du ja nur Zertifikate brauchst und keine PKI, ist das für "kleine" Zwecke erheblich einfacher und sicherer. Gruß, Nils

Moin, na, und noch so ein Missverständnis, das wir ausräumen können. Für einzelne Server-Zertifikate brauchst du ja keine CA bzw. PKI. Im Gegenteil, für so einen Zweck würde ich sogar entschieden davon abraten. Es geht normalerweise darum, dass Zertifikate vorliegen, denen die Systeme vertrauen. Das kann man mit minimaler Infrastruktur einrichten, für die man keine komplexen und anfälligen Systeme braucht. Exemplarisch habe ich das hier mal skizziert: [LDAPS in einer Windows-Domäne ohne PKI | faq-o-matic.net] https://www.faq-o-matic.net/2024/06/18/ldaps-in-einer-windows-domne-ohne-pki/ Gruß, Nils PS. PKI ist böse.

Moin, das hat jetzt aber schon was davon, das Haar in der Suppe zu suchen. Auf zwei Nicht-AD-Hosts kannst du auf beide genannten "Nachteile" ja gut verzichten. Auch ein lokales Adminkennwort muss man nicht per se regelmäßig wechseln, wenn es ausreichend stark ist. Der Witz an LAPS ist doch primär, dass man von massenweise verwendeten identischen Adminkennwörtern weg will - das kann man für den Use Case doch problemlos organisatorisch sicherstellen. Ähnlich bei Protected Users - die meisten Maßnahmen, die das umsetzt, kommen bei lokalen Systemen ja gar nicht in Betracht, und vom Rest lässt sich ein Großteil organisatorisch abfangen. Wenn ich mir ansehe, wie freimütig die meisten VMware-Systeme in der freien Wildbahn so eingerichtet sind, sehe ich da wirklich keinen grundsätzlichen Nachteil ... Gruß, Nils

Moin, nein, DCs sind Tier-0. Falls diese DCs auf einem VM-Host laufen, dann ist dieser VM-Host auch Tier-0, auch dann, wenn der Host selbst nicht dem AD angehört. (Und, der Vollständigkeit halber, dann ist auch das Storage Tier-0, das dieser Host nutzt.) Laufen keine Tier-0-VMs auf einem Host, dann ist der Host nicht Tier-0, auch nicht, wenn er selbst AD-Mitglied ist. Und, wie Evgenij schon betonte, das gilt für alle Hypervisoren, wäre also mit VMware, Proxmox et al. nicht anders. Gruß, Nils

Moin, also ... die einfache Antwort ist: Nur weil es "Cluster" heißt, ist das heute nix Wildes mehr. Richtet sich einfach ein, lässt sich einfach verwalten - jedenfalls solange wir von so kleinen Umgebungen reden. Und ein automatisches Failover für VMs ist auch gleich mit drin. Ich würd da nicht lange nachdenken. Nur weil VMware die besseren Verwaltungstools hat, ist Hyper-V noch lange nicht schlecht. Einfach mal überwinden und machen, dann sieht man, dass man damit auch gut klarkommt. Gruß, Nils

Moin, Und als Fernziel steht das Geschäftsmodell am Horizont, das ohne Kunden auskommt. Gruß, Nils

Moin, ein früherer Kunde von mir kokettierte Anfang der Nullerjahre immer mit der Feststellung, dass seine User immer noch den Exchange Client 4.0 einsetzen würden. Dazu Schedule+ (was er so vorlas, also "scheduhle-plus") für den Kalenderzugriff. Zu dem Zeitpunkt lief auf dem Backend "schon" Exchange 5.0. Den haben wir per Holzhammer da wegmigriert, weil der Rest der Umgebung auch so war - also neue Domain und PST-Import. Das war immerhin eine Hochschule. Wenn auch eine ziemlich kleine. Gruß, Nils

Moin, ich muss da jetzt mal die Systemhäuser in Schutz nehmen ... es ist keineswegs so, dass man dort einfachen Zugriff auf sämtliche Winkel und Details von Microsofts Lizenzverträgen hat. In komplizierten Situationen bekommt man als MS-Partner auch nicht immer hinreichend Support vom Distri. Und dann steht man auch als Partner ziemlich im Regen, zumal man an den Lizenzen selbst in aller Regel nicht ernsthaft verdient. Ja, ich weiß, das hilft einem als Kunden auch nicht weiter. So ist das leider mit Quasi-Monopolen. Gruß, Nils

Moin, sehr schön. Danke dir für die Rückmeldung! Gruß, Nils

Moin, dieses hier klingt vielversprechend: https://blog.tinivelli.com/sql-server-not-starting-after-memory-limit-bfe311d634b8 War übrigens nicht schwer zu finden. Die Suchanfrage lautete "sql server set system memory when service does not start" Gruß, Nils

Moin, Aber sehr liebevoll geschrieben. Gruß, Nils

Moin, Gruß, Nils

Moin, sind die Konfigs danach bereinigt worden? Auch ein Fileserver ist ja schnell neu aufgesetzt. Gruß, Nils

Moin, kenne ich gut. Kenne ich sehr gut. Schön, dass es jetzt klappt. Gruß, Nils

Moin, die Gruppe Domain Users ist primär eine einfache Möglichkeit, sämtliche User der Domäne anzusprechen. Sie hat im AD keine direkt zugewiesenen Rechte. Die sehr weitgehenden Leserechte, die normale User im AD haben, kommen vor allem von der Pseudogruppe "Authentifizierte Benutzer", die separat vom System gehandhabt wird. Allerdings hat diese Gruppe standardmäßig das Recht, sich an jedem Mitgliedsrechner der Domäne anzumelden. Im Dateisystem und in Applikationen hat diese Gruppe keine vordefinierten Berechtigungen, aber in vielen Netzwerken wird sie aus Bequemlichkeit auf (zu) viele Dinge berechtigt. Sollte man nicht tun. Standardmäßig wird diese Gruppenmitgliedschaft als "Primäre Gruppe" verwaltet, was eine technische Spezialität ist. Allgemein sollte man an dieser Zuordnung nichts ändern, auch wenn es technisch möglich ist. Gruß, Nils

Moin, die Geräteklasse nennt sich "Smart Pen". In Aktion habe ich sowas noch nicht gesehen, daher bin ich skeptisch, ob es wirklich belastbare Erfahrungen mit sowas gibt. Die Idee finde ich ganz hübsch. Gruß, Nils

Moin, nein, natürlich nicht. In Bezug auf Office 365 ist das ... Schwurblerei. Man darf datenschutzrechtliche Bedenken haben, aber dies ist nicht die passende Stelle. Gruß, Nils

Moin, das wäre ja gut, wenn sie das täten. Leider hüten sich viele aber eben nicht, sondern beraten schlicht falsch. Gerade das Thema "indirekter Zugriff" ist da ein Klassiker. Gruß, Nils

Moin, Dann füge "für die betreffenden User" hinzu. Was ich meine, ist: falls für die User, um die es hier geht, die Zeiterfassung die einzige Windows-Server-Anwendung ist und deshalb nur dafür CALs beschafft werden müssen, dann ist in dem Szenario möglicherweise Windows nicht die geeignete Plattform, weil zu hohe Folgekosten entstehen. Nutzen die betreffenden User hingegen auch schon andere Windows-Dienste, dann brauchen sie auch jetzt schon CALs. Dann sind sie entweder momentan falsch lizenziert, oder sie haben eben schon eine CAL, dann muss auch keine mehr beschafft werden. Dass man von Unternehmen, die Software entwickeln oder verkaufen, oft nicht richtig zu CALs informiert wird, ist leider immer wieder zu beobachten. Gruß, Nils

Moin, und um es ausdrücklich hinzuzufügen: Falls diese Zeiterfassung tatsächlich das einzige ist, was per Windows läuft, und nur deswegen CALs beschafft werden, dann wäre es evtl. sinnvoll, eine Zeiterfassung zu beschaffen, die nicht auf Windows läuft. Für weniger generelle Aussagen müsste man sich das alles im Detail ansehen, aber dafür ist ein Forum nicht geeignet. Gruß, Nils

Moin, aus leidvoller Erfahrung: Schreibt eure Anforderungen auf und priorisiert sie. Sonst werdet ihr euch sehr viel mit Systemen beschäftigen müssen, die an der einen oder anderen Stelle nicht passen. Gruß, Nils

Moin, da die Frage noch niemand gestellt hat: Braucht es in der Umgebung überhaupt Roaming Profiles? In den meisten Netzwerken ist das gar nicht der Fall, und dann sollte man die möglichst schnell loswerden. Die Technik kommt im Wesentlichen aus den Neunzigerjahren und hat noch nie ernsthaft stabil funktioniert. Gruß, Nils

Moin, ja. Gruß, Nils

Moin, nein, das war ja auch nicht zu erwarten. Dafür wirst du ja aber viel Aufwand getrieben haben - wäre der nicht im Troubleshooting der wahrscheinlichen Ursache, nämlich des SQL Servers, besser investiert gewesen? Gruß, Nils