Unser gute Franky hat einen guten Blogeintrag zum Thema interne Zertifikate für Exchange 2013 verfasst: http://www.frankysweb.de/exchange-2013-san-zertifikat-und-interne-zertifizierungsstelle-ca/
Den Tipp von Franky habe ich schon oft benutzt, vor allem in Umgebungen mit einer .local Domain.
Nun habe ich bei einem Kunden mal wieder die interne CA bemüht um die CAS Kommunikation intern damit abzusichern. Nach Anleitung von Franky habe ich eine Zertifikatsvorlage erstellt und damit ein Zertifikat für die Exchange Server ausgestellt.
Nachdem wir dem Zertifikat den Dienst IIS zugewiesen haben konnten wir uns erstaunlicherweise nicht mehr an der EAC anmelden. Also haben wir über den IIS wieder das öffentliche Wildcard-Zertifikat zugewiesen. Siehe da, die Anmeldung an der EAC war wieder möglich.
Microsoft Exchange, Windows Server, Hyper-V und Failover Cluster. Alles aus der Praxis.
Donnerstag, 21. August 2014
Freitag, 8. August 2014
Exchange Migrationen - Übernahme der internen Relay Konnektoren
Die meisten Firmen mit einer Exchange Umgebung haben auf ihren Exchange Servern spezielle Empfangs-Konnektoren konfiguriert welche es internen Systemen erlauben Mails über den Exchange Server zu senden, ohne sich authentifizieren zu müssen. Wie man solche Empfangs-Konnektoren konfiguriert habe ich ein einem früheren Blogpost erläutert: Exchange 2013 - Interner Relay Konnektor erstellen
In diesem Post will ich eine Möglichkeit aufzeigen, wie solche Konnektoren bei einer Migration einfach übernommen werden können.
In einem ersten Schritt werden die erlaubten IPs, welche den Konnektor verwenden dürfen, in eine Variable geschrieben:
$ips = (Get-ReceiveConnector "SRVEXC01\Internal Relay").RemoteIPRanges
SRVEXC01 = Name des Exchange Servers
Internal Relay = Name des Empfangs-Konnektors
Nun kann der neue Empfangs-Konnektor über die Shell erstellt werden. Dabei werden die Remote IPs mit Hilfe der Variable eingefügt:
New-ReceiveConnector -TransportRole FrontendTransport -Name "Internal Relay" –Server "SRVEXCNEW01” -Usage Custom -AuthMechanism ExternalAuthoritative -PermissionGroups ExchangeServers,ExchangeLegacyServers,AnonymousUsers -Bindings 0.0.0.0:25 -RemoteIPRanges $ips
Welche Parameter es für das Cmdlet New-ReceiveConnector gibt ist übersichtlich auf TechNet aufgelistet: New-ReceiveConnector
In diesem Post will ich eine Möglichkeit aufzeigen, wie solche Konnektoren bei einer Migration einfach übernommen werden können.
In einem ersten Schritt werden die erlaubten IPs, welche den Konnektor verwenden dürfen, in eine Variable geschrieben:
$ips = (Get-ReceiveConnector "SRVEXC01\Internal Relay").RemoteIPRanges
SRVEXC01 = Name des Exchange Servers
Internal Relay = Name des Empfangs-Konnektors
Nun kann der neue Empfangs-Konnektor über die Shell erstellt werden. Dabei werden die Remote IPs mit Hilfe der Variable eingefügt:
New-ReceiveConnector -TransportRole FrontendTransport -Name "Internal Relay" –Server "SRVEXCNEW01” -Usage Custom -AuthMechanism ExternalAuthoritative -PermissionGroups ExchangeServers,ExchangeLegacyServers,AnonymousUsers -Bindings 0.0.0.0:25 -RemoteIPRanges $ips
Welche Parameter es für das Cmdlet New-ReceiveConnector gibt ist übersichtlich auf TechNet aufgelistet: New-ReceiveConnector
Donnerstag, 7. August 2014
Installationsprobleme Exchange 2013 - Check whether this is a valid user account
Bei der Vorbereitung einer AD für die Installation von Exchange 2013 wurde mir bei der Ausführung des Befehls "Setup /PrepareAD" folgende Fehlermeldung angezeigt:
Active Directory must be prepared with 'Setup /PrepareAD'. However, the current user account doesn't have the permissions required even though it's a member of the 'Enterprise Admins' group. Check whether this is a valid user account.
Die Meldung ist mal wieder nicht besonders Aussagekräftig. "Du hast alles richtig gemacht aber irgendwas stimmt noch immer nicht, rate doch was es ist ;-)"
Nach längerer Suche haben wir dann das Problem gefunden. Wahrscheinlich durch ein etwas zu ambitioniertes Harding der Domäne wurde die "Default Domain Controller Policy" angepasst. Normalerweise wird über die "Default Domain Controller Policy" den Administratoren das Recht "manage auditing and security log" vergeben.
Durch die Berechtigung der Administratoren können bei der Installation von Exchange auch die Exchange Server eingetragen werden. Bei diesem Kunden war nun die Berechtigung für Administratoren entfernt. Dies war der Grund für die Fehlermeldung. Nachdem der User, unter welchem wir Exchange installieren wollten, diese Berechtigung erhalten hat (gpudate /force) klappte die Vorbereitung der AD ohne Probleme.
Active Directory must be prepared with 'Setup /PrepareAD'. However, the current user account doesn't have the permissions required even though it's a member of the 'Enterprise Admins' group. Check whether this is a valid user account.
Die Meldung ist mal wieder nicht besonders Aussagekräftig. "Du hast alles richtig gemacht aber irgendwas stimmt noch immer nicht, rate doch was es ist ;-)"
Nach längerer Suche haben wir dann das Problem gefunden. Wahrscheinlich durch ein etwas zu ambitioniertes Harding der Domäne wurde die "Default Domain Controller Policy" angepasst. Normalerweise wird über die "Default Domain Controller Policy" den Administratoren das Recht "manage auditing and security log" vergeben.
Durch die Berechtigung der Administratoren können bei der Installation von Exchange auch die Exchange Server eingetragen werden. Bei diesem Kunden war nun die Berechtigung für Administratoren entfernt. Dies war der Grund für die Fehlermeldung. Nachdem der User, unter welchem wir Exchange installieren wollten, diese Berechtigung erhalten hat (gpudate /force) klappte die Vorbereitung der AD ohne Probleme.
Abonnieren
Posts (Atom)