NilsK

Moin, ich habe die Konfig von 2. und 3. noch nicht verstanden. Die VMs sind auf 2., also SSDs. Und was für Speicher ist 3.? Was genau liegt da, und wie ist das konfiguriert? Und wie genau testest du da? Handelt es sich bei 2. um Enterprise-SSDs? Gruß, Nils

Moin, das AD hat kein Problem damit, mehrere Domänen im selben Subnetz zu betreiben. Alles andere wäre dann Frage des Konzepts und der Anforderungen, zu denen ja anscheinend noch nichts Belastbares bekannt ist. Ein einzelner DC ist bei 15 Usern nicht genug. DHCP hat mit dem AD nichts zu tun. Gruß, Nils

Moin, OK, dann klingt das für mich, als sollte man die vorhandene PKI einfach wegwerfen und eine neue ordentlich aufbauen. Gruß, Nils

Moin, Mach es doch lieber ordentlich. Neuen Server mit aktuellem OS und aktuellem SQL. Datenbank vom alten Server sichern und auf dem neuen wiederherstellen. P2V kann gehen, muss es aber nicht. Vor allem nicht mit antiken Systemen. Gruß, Nils

Moin, der DC wird durch das Entfernen der PKI nicht beeinträchtigt. Gruß, Nils

Moin, ob Admin oder nicht, ist für dein Problem ohne Bedeutung. Trotzdem ist es natürlich nicht OK, dass User auf einem PC Adminrechte haben, schon gar nicht auf so einem PC. Das Phänomen, das du beschreibst, ist so. Das wirst du auch nicht wirksam umgehen können, solange der Shared User auf dem Rechner angemeldet bleibt. Sinnvoll wäre also der Umstieg auf personalisierte Konten auf diesem Rechner. Den Anmeldevorgang könnte man ja ggf. vereinfachen, z.B. über eine PIN-Anmeldung an diesem Rechner. Gruß, Nils

Moin, naja, immerhin ist das Problem identifiziert und behebbar. Jetzt, nach deinem Hinweis, finde ich dazu auch dies. Das gab es bislang nicht als Requirement, weil die Port-443-Verbindung an der Stelle ja neu ist. https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-2016-requirements Danke für die Rückmeldung! Gruß, Nils

Moin, dass du dir mal Gedanken über ein Recovery-Konzept machen solltest, liegt jetzt sicher auf der Hand. Gruß, Nils

Moin, geht es denn über den WAP, wenn du mit Kennwort authentisierst? Gruß, Nils

Moin, die Rede ist hier ja sicher von der Datenbank. Natürlich versucht Exchange nicht, sich aus irgendwelchen Quellen noch zusammenzusuchen, was es bekommen kann. Solltest du wirklich gezwungen sein, eine so alte Datenbank zurückzuspielen, dann ist das eben der Stand, den die Datenbank hat. Irgendwelche Rettungsversuche einzelner Daten aus anderen Quellen müsstest du manuell vornehmen. Gruß, Nils

Moin, so eine Webseite sehe ich auch als einzige sinnvolle Möglichkeit. Wirklich schwer ist sowas nicht zu implementieren, aber man müsste es eben machen. Gruß, Nils

Moin, worum denn sonst? Direkt auf dem Host Software zu betreiben, ist weder sinnvoll noch empfohlen. Da ein Hyper-V-Host sich an einigen Stellen völlig anders verhält als ein "normaler" Server können hier durchaus Ursachen für Probleme liegen. So ist eine Netzwerkkarte im Host nicht einfach eine Netzwerkkarte ... Installiere eine VM für die betreffende Software und richte dort das VNC ein, wenn benötigt. Falls es da auch Probleme gibt, ist das die richtige Stelle, sie zu lösen. Gruß, Nils PS. von der Lizenzfrage, die sich völlig anders stellt, wenn auf dem Host noch was anderes als Hyper-V läuft, sehen wir jetzt mal ab.

Moin, nein. Gruß, Nils

Moin, ja, für den Fall gilt, was lefg sagte: Gruß, Nils

Moin, da steht doch ein Ergebnis. Dass manche Applikationen auf Terminalservern dazu neigen, nach gewisser Zeit nicht mehr ordentlich zu arbeiten, ist (leider) nicht neu und (leider) immer noch oft so. Gruß, Nils

Moin, willkommen an Board! Bitte kapere keine fremden Threads. Eröffne ein neues Thema, auch wenn dir deine Frage ähnlich erscheint. Der Erfahrung nach sind es praktisch nie "dieselben" Fragen, also ist ein neuer Thread besser. Gruß, Nils

Moin, wenn es zu vernachlässigen ist - wäre es dann nicht sinnvoller, dem User direkt Berechtigungen auf den Share zu geben, der das Laufwerk tatsächlich verbinden soll? Gruß, Nils

Moin, es ist i.d.R. empfehlenswert, PowerShell-Skripte als GPO-Skript nicht direkt aufzurufen, sondern über einen Caller-Batch. Der kann dann auch dafür sorgen, die Execution Policy für die aktuelle Ausführung zu setzen. https://blogs.technet.microsoft.com/heyscriptingguy/2011/01/06/use-powershell-and-group-policy-for-your-logon-script/ EDIT: ... und Kennwörter im Klartext in ein Skript zu schreiben, ist eine ganz schlechte Idee. Gruß, Nils

Moin, dann ist es aber keine Child Domain, sondern ein separater Tree im bestehenden Forest. Und das geht schon seit Windows 2000. Um die Vertrauensstellungen schnell anzuzeigen, eignet sich netdom /query trust Oder halt José. ;) Gruß, Nils

Moin, hm ... fast. Beim Hochstufen eines Servers zum ersten DC einer neuen Domäne werden die lokalen User in AD-Userkonten umgewandelt. Beim Hochstufen eines Servers zum zusätzlichen DC einer vorhandenen Domäne werden dessen lokale Konten gelöscht. Beim Herunterstufen eines DCs zum normalen Server erzeugt dieser eine neue lokale Benutzerdatenbank und hat keine lokalen User. Die lokalen User, die es vor dem Hochstufen evtl. gab, sind nicht mehr vorhanden. Das können sie auch nicht, weil der Server beim Herunterstufen eine neue SID erhält und damit eine neue Sicherheitsautorität ist. Windows-NT-Server konnte man nicht zu Domänencontrollern hochstufen. Gruß, Nils

Moin, OK, dann könnte man in die Richtung Vertrauensstellung und gemeinsamer Tenant überlegen. Gruß, Nils

Moin, ich weise mal darauf hin, dass wir uns hier in einem öffentlichen Forum befinden. Kommentare zu Personen haben da IMHO nichts zu suchen. Gruß, Nils

Moin, handelt es sich um zwei getrennte Unternehmen, die hier und da mal Daten austauschen wollen? Oder hat es den Charakter eines gemeinsamen Unternehmens, die quasi "alles" miteinander teilen? Ein gemeinsamer Tenant wäre nur für das zweite Szenario sinnvoll. Gruß, Nils

Moin, oh, das ist ein weites Feld. https://support.office.com/en-us/article/Understanding-Office-365-identity-and-Azure-Active-Directory-06a189e7-5ec6-4af2-94bf-a22ea225a7a9 Du könntest einen Trust zwischen den Forests einrichten und mit "Federated Identities" arbeiten. So ein Deployment ist aber nicht "mal eben" eingerichtet, da wäre Unterstützung schon sinnvoll. Gruß, Nils

Moin, möööp - du kannst zwei unabhängig existierende Domains nicht zu einem Forest (Gesamtstruktur) zusammenfügen. Wenn du das willst, musst du eine neue Domäne in einem der beiden bereits existierenden Forests anlegen und dann alle Objekte und Ressourcen dorthin migrieren. In dem Fall wäre es aber in nahe 100% der Fälle viel schlauer, alles auf eine einzelne Domäne zu konsolidieren, also alle Objekte und Ressourcen der zweiten Domäne gleich direkt in die erste zu migrieren. Die Frage nach dem AAD Connect stellt sich erst dann konkret, wenn das Verfahren bezüglich der Domänenstruktur festgelegt ist. Gruß, Nils