NilsK

Moin, es ist ja auch ein neues Original. Gruß, Nils

Moin, am besten wäre es, sich mit einem kompetenten Dienstleister in Ruhe hinzusetzen und die Anforderungen sowie die Rahmenbedingungen in Ruhe zu besprechen. Das ist in einem Forum nicht zu leisten. Gruß, Nils

Moin, Es ist in diesem Kontext doch völlig egal, wie da zugegriffen wird. Relevant ist, auf was die Anwender zugreifen, also was für Daten und Dienste sie brauchen. Gruß, Nils

Moin, Da sollte man sich in Ruhe zusammensetzen, die Anforderungen klären und dann planen. "Nur noch Cloud" etwa sagt sich leicht, ist aber selten einfach so umzusetzen. Die technischen Details, die du aufzählst, sind eher Nebensache. In erster Linie ist das große Ganze und das Organisatorische zu klären. Gruß, Nils

Moin, wenn das Herunterstufen korrekt geklappt hat, dann ist für das AD alles in Ordnung. Ebenso dürfte auf dem Server alles soweit in Ordnung sein, dass er nun weiß, dass er ein Memberserver ist. Das Entfernen des Features bedeutet nur noch, dass die zugehörigen Programmdateien aus dem OS entfernt werden. Das ist aber funktional gesehen völlig unkritisch. Gruß, Nils

Moin, ja, leider gibt es Kunden, bei denen man solche Konstrukte auch mit Engelszungen nicht los wird. Eine gute Lösung mit genereller Aussicht auf Erfolg habe ich da auch noch nicht gefunden. Ich delegiere das dann immer an andere Mitarbeiter ... Gruß, Nils

Moin, wieso, bei wem ist das denn anders? Gruß, Ni"ich könnt schon wieder"ls

Moin, dem Web nach ist das ein Programm, das Ports umleitet. Das wird anscheinend mit diverser Software installiert. @KorF, ich nehme mal an, das ist ein Testsystem. Im Zweifel platt- und neu machen. Falls es ein Produktionssystem ist, solltet ihr prüfen, was ihr da als Grundlage für Clustersysteme nutzt. Solchen Installationen sollte man blind vertrauen können und daher wissen, was da läuft. Gruß, Nils

Moin, ah, danke. Ich meinte aber noch was anderes; zumindest in meiner Erinnerung gab es sowas wie ein Spezifikationsdokument, das auch angab, für welche Felder das gilt. Mag aber auch sein, dass die Erinnerung da trügt. Gruß, Nils

Moin, ach ja, das Matching ist in der Tat wichtig. Active Directory behandelt (zumindest in vielen Zusammenhängen) Umlaute wie die zugehörigen Vokale. "Müller" ist also gleich "Muller". Ich hatte dazu auch mal eine Dokumentation gefunden, finde sie aber gerade nicht wieder. Gruß, Nils

Moin, ja, das mit dem Backslash als Escape-Zeichen kennt schon, wer den Objektnamen von Usern gemäß deutschen Gepflogenheiten schreibt (Dimpflmoser, Johanna). Eine der beliebten Stolperstellen. Es gibt eine ganze Menge solcher Sachen im AD, die ich bei der Arbeit an meinem Dokutool José immer so peu à peu kennengelernt habe. Das resultierte dann in -zig Sonderlocken im Code. Ich wollte dazu auch immer mal ein Buch schreiben, hatte dann aber nicht ausreichend Muße dazu. Für einen meiner besten Vorträge auf der cim (damals noch ice) hat es aber gereicht. Gruß, Nils

Moin, das hat mit dem ursprünglichen Thread aber nichts zu tun, oder? Künftig bitte einen neuen Thread für eine neue Frage aufmachen. Danke. Grundsätzlich spricht in beiden Fällen nichts dagegen, aber beim SQL Server ist noch etwas Arbeit nötig, damit er hinterher auch ordentlich läuft. [Rename a computer that hosts a stand-alone instance of SQL Server - SQL Server | Microsoft Learn] https://learn.microsoft.com/en-us/sql/database-engine/install-windows/rename-a-computer-that-hosts-a-stand-alone-instance-of-sql-server?view=sql-server-ver16 Gruß, Nils

Moin, hängt halt immer von den Applikationen ab, die darauf zugreifen. Die können sich dann unterschiedlich d*mm anstellen. Bei Leerzeichen gibt es zumindest kein Codepage-Problem. Und LDAP-Filter irgendwo zu nutzen, ist nie eine Freude. Gruß, Nils

Moin, da es hier um den Anzeigenamen geht: Der ist nach meiner Erfahrung unkritisch. Der wäre im Zweifel aber auch leicht und ohne größere Abhängigkeiten zu ändern. In Objektnamen hingegen wäre ich auch konservativ. Ein Kunde hatte mal Schrägstriche in seinen OU-Namen. Das ist echt mal ne bl*de Idee. Gruß, Nils

Moin, aber dann bau das doch einfach so, wie es gedacht ist. Das Grunddesign von S2D sieht vor, dass Hypervisor - also Hyper-V - und Storage auf demselben System sind. Hieraus bildet man einen Cluster aus mehreren Systemen (sinnvollerweise mind. drei; für Testzwecke usw. geht es auch schon mit zweien), sodass Ausfallsicherheit für die VMs gegeben ist und der Storage automatisch vom System repliziert wird. Für den Hypervisor handelt es sich logisch um lokalen Speicher, sodass kein iSCSI usw. nötig ist. Da es die Technik seit Windows Server 2016 gibt, wirst du einiges an Dokumentation dazu finden. Gruß, Nils

Moin, ich glaube immer noch, dass du auf dem falschen Dampfer bist. Wenn es dir darum geht, Storage bereitzustellen, der auf anderen Systemen genutzt wird, dann ist Storage Spaces Direct nicht die richtige Technik. In dem Fall brauchst du einfach einen Speicherpool und das iSCSI Target (oder meinethalben auch NFS - aber das wird dann auch schon immer praxisferner). Für den Pool würde man dann in der Praxis auch eher ein konventionelles RAID nehmen. Gruß, Nils

Moin, Dann hat du es ja bestätigt: wenn die Anforderungen an Verfügbarkeit des Systems so hoch sind, dann braucht es andere Prozesse. Das ist keine Kritik an dir persönlich, sondern ein ernst gemeinter Hinweis. Gruß, Nils

Moin, wenn ein Reboot für dich schon ein "finaler Rettungsschuss" ist, solltest du dringend an deinen Betriebsprozessen arbeiten. Gruß, Nils

Moin, Vielleicht warten wir erst mal ab, was denn der TO zu seinen Plänen sagt. Gruß, Nils

Moin, Wenn du das regelmäßig machst, wäre es dann keine Option, das Gerät in die Domäne aufzunehmen? Gruß, Nils

Moin, was soll das denn werden, wenn es fertig ist? S2D ist primär eine Hyperconverged-Lösung, man würde damit also eher "lokalen" (aber replizierten) Speicherplatz für eine Hyper-V-Umgebung bereitstellen. Es ist vom Design her nicht als SAN-Ersatz gedacht, der beliebigen externen Hosts Storage bereitstellt. Beschreib doch bitte mal, was du vorhast. Gruß, Nils

Moin, Ihr habt gesehen, dass nicht der TO die jüngsten Ergänzungen in diesem Thread gemacht hat? Ich glaube, ttom ist gar nicht derjenige, der die Anforderung hat. Gruß, Nils PS. Die Aussagen zum BR durften hier kaum zutreffen, außerdem kann ein Mitarbeiter nicht einfach so fordern, dass Anweisungen schriftlich erfolgen. Mit solchen Aussagen sollten wir zurückhaltend umgehen.

Moin, manchmal bin ich so froh, dass ich Dienstleister bin und kein Admin. Gruß, Nils

Moin, und je nach Use Case wäre ein CRM oder ganz was anderes besser ... just sayin'. Gruß, Nils

Moin, hm, also für mich klingt das insgesamt so, als sollte man noch mal prüfen, ob der ganze Ansatz passt. Ich könnte mir vorstellen, dass 15.000 Kontakte in einer Outlook-Mailbox nicht nur an der Stelle problematisch sind. Gruß, Nils