pipen

vor 4 Minuten schrieb NorbertFe:

DNS-Server  . . . . . . . . . . . : 192.168.20.1
                                       192.168.20.254

 

Ich vermute mal, dass der zweite der Router ist. Weg mit dem Mist.

Mist ist weg. Problem bleibt.

Client im AD:

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : EW159
   Primäres DNS-Suffix . . . . . . . : ad.domäne.com
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : ad.domäne.com

Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix: ad.domäne.com
   Beschreibung. . . . . . . . . . . : Intel(R) Ethernet Connection (2) I219-LM
   Physische Adresse . . . . . . . . : 3C-52-82-62-DF-14
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::4148:f789:a6d6:b4a%3(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.20.206(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Dienstag, 12. November 2019 07:51:24
   Lease läuft ab. . . . . . . . . . : Mittwoch, 20. November 2019 08:01:58
   Standardgateway . . . . . . . . . : 192.168.20.254
   DHCP-Server . . . . . . . . . . . : 192.168.20.1
   DHCPv6-IAID . . . . . . . . . . . : 54284930
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-24-59-8C-2A-3C-52-82-62-DF-14
   DNS-Server  . . . . . . . . . . . : 192.168.20.1
                                       192.168.20.254
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Client nicht im AD:

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : EW121
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein

Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Intel(R) Ethernet Connection I219-LM
   Physische Adresse . . . . . . . . : FC-45-96-65-5F-D8
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.20.11(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.20.254
   DNS-Server  . . . . . . . . . . . : 192.168.20.1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

vor 3 Stunden schrieb Dukel:

Hat zwar nichts mit Exchange zu tun, aber ein DC ist idR zu wenig.

 

Geht es jetzt mit den Einträgen?

Ich habe die cmds nicht ausgeführt, weil ich ja die Zonen schon hatte. Oder soll ich die jetzt nochmals ausführen?

dnscmd . /zoneadd outlook.<domain.tld> /dsprimary

dnscmd . /zoneadd autodiscover.<domain.tld> /dsprimary

dnscmd . /recordadd outlook.<domain.tld> . A <IP des Exchanges>

dnscmd . /recordadd autodiscover.<domain.tld> . A <IP des Exchanges>

UPDATE:

jetzt habe ich gerade Intern von einem Client der nicht im AD ist, nslookup autodiscover.domäne.com aufgerufen und der hat die richtigen Einträge ausgegeben.

Server:  dc1.ad.domäne.com
Address:  192.168.20.1

Name:    autodiscover.domäne.com
Address:  192.168.20.2

Intern von einem Client im AD besteht das Problem weiterhin......

Ja, es gibt nur einen DC. Dann kanns ja kein DNS Problem auch nicht sein, oder?

Die Zonen habe ich schon mal erstellt. Was mir auffällt ist das bei mir noch zwei Einträge drin sind. Sind die überflüssig?

In der Testumgebung hats einwandfrei funktioniert, deshalb hab ich es ohne DL gemacht.....

Also mittlerweile ist Kaspersky Mail Server davor. Problematik bleibt. Ausserdem bekomme ich mit dem cmd nslookup autodiscover.domäne.com eine falsche Antwort. Die Konfig bin ich mittlerweile 2x durch, ich kann den Fehler nicht finden....

[PS] C:\Windows\system32>nslookup autodiscover.domäne.com 
Server:  dc1.ad.domäne.com
Address:  192.168.20.1

Nicht autorisierende Antwort:
Name:    autodiscover.domäne.com.domäne.com
Address:  88.198.101.230

Ich bin dabei die Clients mit Outlook an Exchange zu verbinden. Dabei ist mir aufgefallen das die Windows 10 Clients problemlos funktionieren aber die Windows 7 Clients machen zum Teil massive Probleme. Ich bekomme eine Zertifikatsmeldung. Das Zertifikat weisst dann nicht mein SSL Zertifikat aus, sondern das Zertifikat von der Firewall. Ich vermute mal das es geneau wegen oben stehenden Problematik nicht funktioniert.

Vor dem Exchange ist eine pfSense Firewall mit NAT Weiterleitung. Dann kommt gleich der Exchange mit default Filter.

Normal ja, mittlerweile alles aus.......

Ich kann dazu in den Logs nichts finden. Mail zustellen per Telnet funktioniert. Komisch alle Mails kommen an, aber es dauert bis zu 30 Minuten. Dann kommen sie wieder sofort. Was könnte das nur sein???

ok, vielleicht war ich zu ungeduldig, weil der Empfang mit OWA sowie auch mit Outlook ziemlich lange dauert. Gibt es da einstellbare Zeiten?
Seit der Umstellung zurück auf die Default Werte kommt auch wieder keine Mail mehr an.

Kannst du mir sagen was an meinem Vorgehen falsch ist? Ich wäre Dir sehr dankbar...

Ab Montag Produktiv Umgebung. Die Mails kommen sehr zögernd an. Vor einer halben Stunde habe ich eine Mail versendet, die ist gerade angekommen.

Ich habe die Sicherheitseinstellung für den Default Frontend abgeändert, anschließend kommen auch die Mails durch. Sollte man die Connectoren jetzt so belassen, oder gibt es da etwas zu verändern?

Ich habe auch noch mit Autodiscover ein Problem. Ich habe mir eine Exchange Zertifikatsanforderung erstellt. Diese dann bei der PSW Group eingereicht. Dazu habe ich dann ein SSL Zertifikat erhalten. Im Exchange habe ich dann die Anforderung abgeschlossen und die Exchange Dienste angebunden. Wenn ich jetzt einen nslookup ausführe dann wird von intern nicht richtig aufgelöst. Siehe Bild. An was könnte das liegen? Extern funktioniert der Zugriff auf OWA und ECP.

Sicherheitseinstellungen sind so:

Mails sollten von Exchange angenommen werden. Der DefaultFrontend ist default so konfiguriert:

Hallo,
wir haben einen neuen Server bekommen. Dieses Wochenende ist die Umstellung. Folgende VM's sind am Laufen:
- dc1 als Domaincontroller mit DNS und DHCP
- s1 Exchange Server
Die Domäne heißt ad.domäne.com. Die Server sind Server 2019 Standard und der Exchange ist ein 2019. Das Netz ist in einem eigenen VLAN. Als Firewall wird eine pfSense eingesetzt. Hier wurde die eingehenden NAT Regeln vom alten Exchange auf den neuen Exchange umgestellt.
Eigentlich funktioniert alles soweit. Der Exchange kann Mails nach Extern versenden, und intern an die mails@ad.domäne.com auch. Womit ich jetzt nicht klar komme, wie ich die Empfangsconnectoren konfigurieren muss, damit ich auch Mails empfangen kann. Kann mir das bitte jemand von Euch erklären?

vor 1 Minute schrieb Dukel:

Das nennt sich IIS.

Klar, sorry schreibfehler.

vor 3 Minuten schrieb NorbertFe:

Ja, warum nicht? Und was hat das mit "Forest" zu tun?

 

Bye

Norbert

Danke, war nur so ein Gedanke und wollte sichergehen.....

Hallo,

ich benötige wiedermal Eure Hilfe. Ich bin gerade dabei, bzw. ich habe einen neuen Server Forrest mit einer neuen Domäne aufgesetzt. Domäne ad.domain.com

Die einzelnen VM’s laufen auf einem Server mit VMWare 6.7.

-          dc1 Server 2019 Standard als Domaincontroller mit DNS und DHCP

-          s1 Server 2019 Standard mit Exchange 2019

-          s2 Server 2019 Standard als WSUS, Dateiserver, Druckserver

Beim s1 mit Exchange läuft jetzt der IIS Dienst und auf dem s2 läuft ebenfalls der IIS Dienst der bei der WSUS Rolle mitinstalliert wurde. Kann man die so „nebeneinander“ Problemlos laufen lassen?

Ich möchte mich recht herzlich für Eure Beiträge bedanken.

Für die Enterprise-CA in der Domäne sollte ja der Server 2012R2 Standard ausreichen, oder?

What are some of the features now available in Windows Server 2012 Standard that were previously only available in Windows Server 2008 R2 Enterprise and Datacenter editions?

There are a variety of new features in Windows Server 2012 Standard edition. Here are just a few examples of what was previously only available in the premium editions:

· Windows Server Failover Clustering

· BranchCache Hosted Cache Server

· Active Directory Federated Services

· Additional Active Directory Certificate Services capabilities

· Distributed File Services (support for more than 1 DFS root)

· DFS-R Cross-File Replication

Nach reichlicher Überlegung habe ich mich dazu entschieden nicht zu migrieren, sondern eine neue, saubere Umgebung zu schaffen. Außerdem wäre die Migration nicht ohne Zwischenschritt möglich gewesen. Wenn ich dann abwäge zwischen den Altlasten des SBS und der Arbeit für die Neuinstallation habe ich mich für letzteres entschieden.

Ich möchte Software mit Windows Package Publisher über den WSUS verteilen lassen. Dafür benötige ich ein Zertifikat. Also brauche ich auch eine funktionierende PKI, oder kann ich das anders besser lösen?

Der Forrest soll in naher Zukunft unsere alte Domäne mit altem Server ablösen…
Bevor ich die Sub-CA in die Domäne integriere wollte ich mich zuerst doch nochmal schlau machen und mir Meinungen einholen wie ich es am besten anpacke.

Genau beim Einsatz von Zertifikaten stellt sich mir die Frage wo sie intern wirklich Sinn machen.

Hallo,

ich bin gerade dabei, bzw. ich habe einen neuen Server Forrest mit einer neuen Domäne aufgesetzt. Domäne ad.domain.com

Die einzelnen VM’s laufen auf einem Server mit VMWare 6.7.

-          dc1 Server 2019 Standard als Domaincontroller mit DNS und DHCP

-          s1 Server 2019 Standard mit Exchange 2019

-          s2 Server 2019 Standard als Dateiserver

-          s5 Server 2012r2 als Zertifizierungsstelle (nicht in der Domäne)

Das externe Zertifikat für den Exchange habe ich. Es wurde für outlook.domain.com und autodiscover.domain.com ausgestellt und ist schon für unseren alten Exchange im Einsatz.

Ich bin jetzt bei den Zertifikaten angekommen und bin mir hierbei nicht ganz sicher welche Zertifikate ich einbinden bzw. ausstellen soll. Da ich jetzt alles neu mache möchte ich mir hier keinen Fehler einbauen.

Vielleicht könnt ihr mir hilfreiche Tipps geben. Dafür wäre ich Euch sehr dankbar.  

Gruß Christian

Hallo,

also die Umstellung auf NTLM war problemlos. Das Problempostfach konnte auch irgendwie wieder verbunden werden. Ich kann nicht sagen woran es gescheitert hat. Vielen Dank nochmals für die Unterstützung.