NilsK

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

Moin, Verstehe. Zu dem 500 kann ich auf der Ferne leider wenig sagen. Hast du schon die verschieden logging-Methoden eingesetzt? Gruß, Nils

Moin, also nur Zertifikate, kein MFA? In dem Fall würde ich prüfen, ob sich das per Smartcard oder auf andere Weise lösen lässt. Clientzertifikate auf dem Rechner haben eine Reihe von Einschränkungen und Nachteilen: Die Zertifikate müssen erst einmal beim User oder auf dem Device landen. Hat der User mehr als ein Zertifikat, dann muss er jedes Mal auswählen, welches er denn zücken will. Das kann ein typischer User aber kaum unterscheiden. Automatisch verteilte Zertifikate haben immer nur einen Indizienwert, keinen Nachweiswert: Der User könnte sein Zertifikat exportieren und auf ein anderes Device bringen (oder jemand anderem als Kopie geben). (Ja, das geht auch, wenn die Zertifikatsvorlage keinen Export zulässt.) Je nach Browser kann es passieren, dass der Browser das Zertifikat jeder Webseite übermittelt, die danach fragt - was eine prima Möglichkeit ist, an Daten des Users zu gelangen. ... Wie ist denn die Anforderung genau definiert? Reicht ein "seamless SSO" nicht vielleicht schon aus, sodass man sich nur um die Windows Integrated Authentication kümmern müsste? Gruß, Nils

Moin, mag sein, aber du hast meine Frage auch noch nicht beantwortet, warum es denn Clientzertifikate sein sollen. Gruß, Nils

Moin, Schau an, gut zu wissen. Es bleibt aber dabei, dass Client-Zertifikate für Webseiten großer M*st sind. Gruß, Nils

Moin, ADFS und Zertifikate ist ... nicht eben toll. Spätestens wenn du von einem Hotel oder so kommst, wo der extra benötigte TCP-Port 49443, den ADFS für Zertifikatsanmeldung braucht, nicht frei ist, wirst du das merken. Vielleicht ist das auch hier schon der Grund. Was ist denn der Grund für die Einbindung von Zertifikaten? Die haben ja schon prinzipiell eine Reihe von Nachteilen. Gruß, Nils

Moin, nein, das Management von IPv6 funktioniert vollständig anders als das von IPv4. Versuche nicht, die bekannten Mechanismen zu übertragen, das wird nicht gehen. Zum Thema Speedport und IPv6 findest du hier im Board schon einiges. Kurze Erläuterungen zu IPv6 sind nicht zielführend. Ich finde das Buch "Practical IPv6 for Windows Administrators" von Edward Horley sehr nützlich. Muss man sich aber Zeit für nehmen, und da rede ich nicht von ein paar Stunden. Gruß, Nils

Moin, ja, das ist ein Bug, der kurz vor RTM ins System kam. Anscheinend ist der noch nicht behoben worden. Gruß, Nils