Jump to content

Mack

Members
  • Content Count

    49
  • Joined

  • Last visited

Community Reputation

10 Neutral

About Mack

  • Rank
    Newbie
  1. Ich bin noch das finale Feedback schuldig, als dass die Nachwelt von meinen "Leiden" profitieren kann. Also, das dcpromo lief tatsächlich sauber durch, nachdem beide DCs via SMB1 miteinander quatschen konnten.
  2. Definitiv. Auf (hoffentlich) nicht allzu lange Sicht ist der 2008 ja eh weg. Dort konnte ich jetzt nur testweise nicht am SMB spielen wg. dem Neustart.
  3. Ah, das könnte natürlich sein und klingt "praxisnah" . Danke für den Hinweis.
  4. Also, Ich bin schon etwas weiter und verhalten optimistisch die Ursache gefunden zu haben. Ich habe mir mal das SMB auf dem 2008 R2 angeschaut und der läuft noch auf SMB1, was auf dem Server 2019 ja standardmäßig deaktiviert ist. So habe ich jetzt mal testweise SMB1 auf dem neuen Server zugelassen. Den Neustart dort kann ich gerade durchführen und siehe da: Ich kann vom alten DC den neuen in der AD GUI verwalten, bei den Betriebsmasterrollen wird der aktuelle (neue) nicht mehr als FEHLER - offline angezeigt. Ein dcdiag vom alten zum neuen
  5. Windows-IP-Konfiguration Hostname . . . . . . . . . . . . : ALTER SERVER Primäres DNS-Suffix . . . . . . . : DOMAIN.TLD Knotentyp . . . . . . . . . . . . : Hybrid IP-Routing aktiviert . . . . . . : Nein WINS-Proxy aktiviert . . . . . . : Nein DNS-Suffixsuchliste . . . . . . . : DOMAIN.TLD Ethernet-Adapter LAN-Verbindung: Verbindungsspezifisches DNS-Suffix: DOMAIN.TLD Beschreibung. . . . . . . . . . . : Broadcom BCM5708C NetXtreme II GigE (NDIS VBD Client) Physikalische Adresse . . . . . . : 00-18-8B-31-20-12 DHCP aktiviert. . . . . . . . . . : Nein Autoko
  6. Nein, da ist keines definiert. Dort sind lediglich die Default Einstellungen hinterlegt ("Standardname-des-ersten-Standorts")
  7. Ich beziehe mich auf die Ereignisanzeige, Administrative Ereignisse, Also Anwendung, System, Active Directory, DNS Server etc.
  8. Ja, beide Server zeigen in den Logs nur wiederkehrende DFSR Events (5014 und 5002) regelmäßig abends um 19:00. Danach findet aber eine erfolgreiche Verbindung statt. Ich sehe auch gerade, um 19:00 findet die Windows Server Sicherung statt. Die automatischen Dienste laufen alle. Vor allen Dingen auch der RPC. Pff, da bin ich auf dünnem Eis unterwegs. Die GC werden zumindest bei beiden angezeigt. Ganz ehrlich, wüsste ich nicht genau, wonach ich da nun schauen muss. VPN bzw. MTU Probleme können wir ausschließen. Sorry, hatte ich nicht erwähnt. Es ist nur ein Standort
  9. Dazu kann ich sagen, dass zumindest IP4 gegenüber IP6 präferiert werden soll (Stichwort DisabledComponents HEX20). Ich bin aber was IP6 angeht ehrlich gesagt wenig bewandert. Aktiv ist da nichts explizit konfiguriert. Der Router macht IP4 Jopp. In den Logs steht nichts. Vielleicht kann man dazu explizit das Logniveau anheben, damit da mehr steht?!
  10. Der war u.a. auch noch DATEV (sag nix, habe ich so übernommen) und aktuell DHCP, sowie vor allen Dingen File Server. DATEV ist wegmigriert. Der DHCP ist natürlich kein Problem. Die Filestruktur ist Kraut und Rüben und soll (muss!) aufgeräumt werden, was sich leider hinzieht. Es muss noch eine Exchange 2016 zu 2019 Migration (andere Server) on Premise laufen und da habe ich halt das Problem mit dem AD Level. Da die Filemigration sich hinzieht, wollte ich schon einmal demoten, damit ich die AD anheben kann für Server 2019 und am Exchange weitermachen kann.
  11. Moin Nils, das ist dazu leider völlig ungesprächig. Sporadisch moppert DFSR, dass er mal eine Verbindung nicht hinbekommen hat. Meldet aber kurze Zeit später die erfolgreiche Verbindung. Ansonsten sind die administrativen Ereignissse erstaunlich leer. Während des DCPromo als solches wird überhaupt nichts geloggt.
  12. Mein Problem ist einen Windows 2008 R2 Server zu demoten. Situation: Eine Windows Domäne mit aktuell zwei Domänencontrollern. Einmal ein Windows Server 2008 R2 und einmal ein Server 2019. Die aktuelle Domänenfunktionsstufe ist auf den maximal möglichen Stand 2008 R2. Beide DC sind natürlich auch DNS. Der primäre DNS des einen zeigt jeweils auf den anderen, der sekundäre auf sich selbst. Ein NSlookup löst die Server und die Domäne korrekt auf. DCDiag zeigt keine Fehler, FRS wurde im Vorfeld auf das aktuelle DFRS ohne offensichtliche Proble
  13. Punkt 1 stimmt und soll auch zeitnah behoben werden. Allerdings ist das nächste Servicefenster erst in 3 Wochen. Punkt 2 verstehe ich leider die Frage nicht. Der Ordner wurde durch einen Mitarbeiter angelegt, welcher die Adressen zukünftig pflegen soll. Der Onlinemode, weil die Outlook`se auf einer RDS Farm laufen und RDS und Exchange laufen als Hyper V auf der gleichen HW Maschine. Problem ist mittlerweile gelöst. Für die Nachwelt: Die Kontakte in der globalen Adressliste hatten ursprünglich die externe Adresse als Haupt SMTP und
  14. Wir haben einen Exchange Server Standard 2016 CU 8. Die Mitarbeiter greifen von Outlook 2016 Clients im Online Mode darauf zu. Bis dato wurden externe S/Mime Kontakte in der globalen Adressliste zur Verfügung gestellt. Nun ist ein neuer öffentlicher Kontakteordner angelegt worden und die Kontakte wurden dort ebenfalls erstellt und mit den öffentlichen Zertifikatsschlüsseln versorgt. Möchte nun ein Mitarbeiter an eine dieser Adressen mailen, bekommt er den Hinweis: "Diese E-Mail-Nachricht kann nicht zugestellt werden, weil deren E-Mail-Adresse nicht
  15. Mensch zahni, da hätt ich auch drauf kommen können/sollen. Ich hab es nur aus Outlook heraus getestet und in der Tat versäumt, Outlook auch für die Teilen-Funktion freizuschalten. So klappt es tatsächlich. Einziger Haken, ich habe weniger Optionen die Bilder zu verkleinern, als via Mail. Aber dennoch ggf. eine "Not"-Lösung. Danke schon mal. Da es zur Zeit bei der Domain keine Möglichkeit gibt MX und DNS Einträge zu setzen, gibt es auch kein offizielles Zertifikat für Exchange. Ergo sind die iPhones zumindest im Moment noch nicht per EAS am Exchange dran. Die Bilder werden über lok
×
×
  • Create New...