testperson

Das Update hat allerdings keine Änderungen "am AD / LDAP" vorgenommen (und kam AFAIK erst im März). Ebenso haben (moderne) OS und Exchange keine Probleme mit den "schon länger" geltenden Best Practice aus dem Bereich.

Ist es der Domain-Admin oder ein Domain-Admin? Falls du mit dem Domain-Admin - mit der SID S-1-5-21-XXX-500 - angemeldet bist, solltest du prüfen, ob du nicht doch mit einem lokalen Konto unterwegs bist. Da wärst du nicht der Erste ;). Mir sind zuletzt immer wieder Umgebungen untergekommen, wo es lokal einen "XYZ-Admin" gab den es bl*derweise auch in der Domäne gab. Hat der neue Exchange-Server ggfs. einen (falschen (IPv6)) DNS Server, der deine Domäne nicht kennt?

Hi, du verbindest die beiden Laufwerke im gleichen GPO? Welche Aktionen hast du bei den Laufwerken gewählt? Ist "Im Sicherheitskontext des angemeldeten Benutzers ausführen" aktiv? Ist ggfs. eine Zielgruppenadressierung auf dem I: Laufwerk? Findet sich etwas im Richtlinien Ergebnis-Satz (gpresult /h %temp%\gpo.html & %temp%\gpo.html)? Ggfs.: https://support.microsoft.com/en-us/help/297684/mapped-drive-connection-to-network-share-may-be-lost Ansonsten Logging aktivieren: https://docs.microsoft.com/en-us/archive/blogs/askds/enabling-group-policy-preferences-debug-logging-using-the-rsat Und prüfen: %ProgramData%\GroupPolicy\Preference\Trace Gruß Jan

So ist es. Dafür könntest du dich hier bedienen: https://www.mcseboard.de/topic/206136-microsoft-windows-server-2016-lizenzierungshilfe/

Hi, um das etwas übersichtlicher und lesbarer zu halten, könntest du die Fehler in einen Zitat- oder Code-Block einbetten. Das wichtigste wird wohl der letzte Fehler sein: Ich vermute, du benutzt einen User, den es auch lokal auf dem Exchange-Server gibt und meldest dich derzeit eben lokal an. Zur Sicherheit, was ergibt denn: # Benutzer: whoami /USER # Gruppen: whoami /GROUPS Des Weiteren solltest du die Installation direkt mit Exchange 2016 CU17 starten. Dann bist du direkt aktuell. Dein Exchange 2010 sollte ebenfalls, sofern er es nicht ist, auf SP3 RU30 sein. Gruß Jan

Hi, AFAIK wirst du mindestens eine Volumenlizenz bzw. Software Assurance in der identischen Edition der "zu klonenden" Software brauchen, damit du die Systeme klonen/reimagen darfst: http://download.microsoft.com/download/3/D/4/3D42BDC2-6725-4B29-B75A-A5B04179958B/Reimaging.pdf Gruß Jan

Wenn ich mich nicht irre, dann ist das was ich meine, genau der Fall für das, sofern du die NAS mit Windows Server Standard lizenzierst und daher dürfte das hier eine Rolle spielen. (Außer natürlich du lizenzierst die NAS, wie im OP angedacht, doch mit Datacenter, dann dürfte es Wurst sein.)

Hier gibt es AFAIK eine Lizenz-neu-zuweisungs-Regelung-im-Hardwareausfall-Fall. Da bin ich aber nicht tief genug im Thema, meine aber, du darfst nach Ausfall des Hyper-V Bleches die Lizenz dem NAS zuweisen. Zurück von NAS auf Hyper-V zugewiesen werden darf die Lizenz dann aber erst nach 90(?) Tagen. Das sollte dir aber jemand mit Ahnung erläutern. Bei dem Vorhaben könntest du evtl. überlegen, das mit zwei identischen Hyper-V Hosts anzugehen und das NAS nur als Backup Storage nutzen. Dann könnten, sofern von den Applikationen unterstützt, die Hyper-Vs ihre VMs auf den jeweils anderen als DR Maßnahme replizieren. Um hier allerdings mehr wie "Kommt drauf an" zu sagen, müsste man weitere Details bzw. entsprechende Anforderungen kennen.

Mir würde spontan nur einfallen, dass du aufpassen müsstest, wenn du VMs von NAS <-> Hyper-V verschieben / replizieren wollen würdest, sofern das mit dem Hypervisor auf dem NAS machbar ist. Hier wäre fraglich, ob die Richtung Hyper-V -> NAS machbar wäre, sofern du die VMs auf dem Hyper-V Host mit Windows Server 201x Standard installieren würdest. Wenn auf dem NAS "nur" ein Domain Controller virtualisiert werden soll, würde ich ggfs. noch überlegen, das nicht zu tun und einen "Mini-Server" ggfs. direkt mit Standard Lizenz zu kaufen um dort den zweiten DC zu betreiben.

Hi, die RDSH Farm(en) nutzen i.d.R. den gleichen Lizenzserver, sofern auch konfiguriert. Du benötigst hier 23 User CALs oder eine entsprechende Anzahl (20 + ggfs. HomeOffice PCs / weitere zugreifende Devices) an Device CALs. Da du von VPN sprichst, würde es vermutlich mehr Device CALs wie User CALs brauchen. User CAL oder Device CAL :-P. So wie du es schilderst -> User CAL. Wie sieht es mit einem Office-Paket auf den Remote Desktop Hosts aus? Das müsste per zugreifenden Devices oder einer "terminalserverfähigen" O365 Lizenz lizenziert (pro User) werden. Du möchtest für eine NAS eine weitere Datacenter Lizenz nutzen? Gruß Jan

Das sollte in halbwegs modernen Browsern auch (einfacher) machbar sein. Im neuen Edge bspw. "Rechte Maustaste" -> "Untersuchen" oder STRG + UMSCHALT + I. Unter Quellen sollte dann zu finden sein, was da ggfs. "fremdes" eingebunden wird.

Feigling! :-P

Hi, das sollte mit dem Mailbox Replication Service / MRSProxy machbar sein und ist hier beschrieben: https://www.msxfaq.de/exchange/migration/org2org2016.htm Habe ich aber noch nie gemacht, wollte es aber schon immer mal in einer Testumgebung nachstellen ;) . Gruß Jan

Was möchtest du denn da letztlich abbilden und wieso muss es zwingend Outlook als Client bzw. Exchange sein?

Hi, evtl. ist Exchange (und Outlook) hier das falsche Mittel zur Wahl. Je nachdem was du (letztlich mit der Konfiguration) erreichen willst, könnte das etwas für ein Ticketsystem o.ä. sein. Gruß Jan

OT: Wenn man den Herrn zwischen "C:\Users\" und "\Desktop\..." nicht mit dir in Verbindung bringen soll oder der Herr hier vielleicht unwissend auftaucht, solltest du den Screenshot ggfs. anonymisieren :).

Hi, wäre es evtl. ein einfacherer Ansatz, die Server im derzeitigen IP-Netz zu belassen und "alles andere" in eigene VLANs / IP-Netze umzuziehen? Alternativ würde ich direkt alle Geräte durchgehen und prüfen, wie diese konfiguriert sind. Dann kannst du direkt die saubere Dokumentation "nachziehen". Gruß Jan

Hi, das klingt danach, als wäre es am zielführendsten sich einen Dienstleister zu suchen, der die Infrastruktur einmal aufnimmt und dann das Design bzw. die Möglichkeiten mit euch durchspricht. So hätte man auch noch jemanden in der Hinterhand, der bei Problemen unterstützen könnte bzw. direkt involviert wird. Wenn die Standorte nicht von einander abhängig sein wollen, wäre es ggfs. auch eine Option Exchange an einem "verfügbareren" Standort C, bspw. O365, zu betreiben. Ebenfalls könnte man beleuchten, ob ein zweiter DC je Standort sinnvoll wäre. Je nach Anforderung(en) könnte es vielleicht auch auf zwei getrennte Gesamtstrukturen (und ggfs. anschließendem Trust) rauslaufen. Meiner Meinung nach: Es kommt drauf an :). Gruß Jan

Hi, naja, Teamviewer liegt da ja nun auch nicht falsch mit der kommerziellen Nutzung. Du könntest die Remotehilfe / QuickAssist oder auch die Remoteunterstützung nutzen: https://support.microsoft.com/de-de/help/4026516/windows-solve-pc-problems-remote-connection-quick-assist Gruß Jan

Wenn ihr nur einen Terminalserver habt auf dem alle User arbeiten und die Anzahl der Drucker "überschaubar" ist, würde ich die Drucker auf dem Terminalserver installieren (und nicht freigeben). Das wird von Microsoft vermutlich noch weniger begrüßt ;).

Hi, das wichtigste wäre die Terminalserver aktuell zu patchen und die aktuellsten Druckertreiber zu nutzen. Zu diesem Problem gibt es hier einiges zu lesen: https://www.mcseboard.de/topic/199355-2012-r2-rds-extreme-druckerprobleme/ Wie viele Terminalserver sind im Einsatz? Was nahezu immer hilft (aber eigentlich keine zufriedenstellende Lösung ist), die Drucker nicht in die User Session verbinden sondern auf den Terminalservern installieren. Gruß Jan

Oha, ich Depp Demnächst auch alles lesen und verstehen. Das betrifft nur "EV-Zertifikate" und sowohl wir, wie scheinbar auch die DKB, nutzen Domain- bzw. Organization-Validated Zertifikate.

Hi, nach https://www.heise.de/news/Jetzt-handeln-DigiCert-erklaert-zehntausende-TLS-Zertifikate-fuer-ungueltig-4840972.html?wt_mc=rss.red.security.security.atom.beitrag.beitrag sollten gestern 20 Uhr verschiedene Intermediates von Digicert revoked werden. In den Kommentaren bei heise.de habe ich als Beispiel die DKB gefunden (und muss nicht drauf eingehen, dass bei "uns" verschlafen wurde, zu erneuern), die noch ohne Zertifikatswarnung aufgerufen werden kann. Die Sperrlisten wurden jedenfalls gestern aktualisiert. Ist das jetzt ein Grund weshalb es https://www.michael-wessel.de/blog/2020/04/27/lets-talk-about-it-warum-pki-ein-krankes-konzept-ist/ gibt? Gruß Jan

Hi, hast du nach dem Update durchgebootet? Laufen alle Dienste? Gab es irgendwelche Besonderheiten beim Update oder lief das komplett problemfrei durch? Sind das die einzigen Fehler im Eventlog oder finden sich in administrativen Ereignissen weitere? Mir sind zuletzt eine Hand voll Exchange Server begegnet wo - losgelost von einem Update - keine Zertifikate mehr ans Backend gebunden waren. Da gab es dann auch entsprechende Serverfehler. Je nachdem wie lange du schon nicht mehr weiter weißt, wäre ggfs. ein Restore eine Idee. Danach würde ich dann direkt auf CU17 updaten. Gruß Jan

Die 12.1-57.18 ist auch nicht betroffen und im 12.1er Release die aktuellste Firmware aus Juni.