Running Server 2012 with Exchange 2013 since 2012, all ok. SSL Cert ran out recently, bought new from Comodo. In the old UC Cert I had 4 names incleded: mail.domain.ch, autodiscover.domain.ch, hostname.domain.ch and the hostname alone. Comodo (and probably other Certs) do no longer accept single hostnames in Certs so I omitted that. Now login to EMC is no longer possible and Outlook can no longer connect. EMS works but obviously with limited command set. Tried Set-ClientAccessServer command. It is not recognized as are others. There are some commands working with "get-excommand" but not those needed to configure FQDN instead of hostname to access the Server. Any help is greatly appreciated.

Marcel

What error do you get when you run a test via testexchangeconnectivity.com ?

PS : you might also want to check set-outlookprovider

Dicicert test shows: Certificate does not match FQDN.

https://testconnectivity.microsoft.com/ Shows (unfortunately all in German):

Error testing Acrtive Sync

Fehler beim Testen der AutoErmittlung fr Exchange ActiveSync (Error testing autodiscover for Active Sync)

Fehler beim Testen der AutoErmittlung (Error testing autodiscover) (same for the next 3 steps)

Der AutoErmittlungsdienst konnte mit keiner Methode erfolgreich kontaktiert werden (the autodiscover service could by no means be contacted)

Es wird versucht, DNS-MX-Eintrge fr Domne 'snnet.ch' abzurufen.
	Mindestens ein MX-Eintrag wurde erfolgreich aus DNS abgerufen.
	Weitere Details   MX-Eintrge Host snlemon.snnet.ch, Einstellung 10 Verstrichene Zeit: 135 ms.

	Mail-Exchanger snlemon.snnet.ch wird getestet.
	Dieser Mail-Exchanger wurde erfolgreich getestet.

(MX entry ok, SMTP mail exchange ok)

Es wird versucht, fr die IP-Adresse 62.2.148.162 Reverse-DNS-Lookups auszufhren.
	Die Microsoft-Verbindungsuntersuchung hat die IP-Adresse 62.2.148.162 erfolgreich ber Reverse-DNS-Lookup aufgelst.
	Weitere Details   Die Microsoft-Verbindungsuntersuchung hat die IP-Adresse 62.2.148.162 als Host 62-2-148-162.static.cablecom.ch aufgelst. Verstrichene Zeit: 376 ms.

	RBL-Test (Real-Time Black Hole List) wird ausgefhrt
	Ihre IP-Adresse wurde in keiner der ausgewhlten Sperrlisten gefunden.
	Weitere Details   Verstrichene Zeit: 9379 ms.
	Testschritte   Sperrliste "SpamHaus Block List (SBL)" wird berprft   Die Adresse befindet sich nicht in der Sperrliste.   Weitere Details   Die IP-Adresse 62.2.148.162 wurde nicht in RBL gefunden. Verstrichene Zeit: 30 ms. Sperrliste "SpamHaus Exploits Block List (XBL)" wird berprft   Die Adresse befindet sich nicht in der Sperrliste.   Weitere Details   Die IP-Adresse 62.2.148.162 wurde nicht in RBL gefunden. Verstrichene Zeit: 53 ms. Sperrliste "SpamHaus Policy Block List (PBL)" wird berprft   Die Adresse befindet sich nicht in der Sperrliste.   Weitere Details   Die IP-Adresse 62.2.148.162 wurde nicht in RBL gefunden. Verstrichene Zeit: 186 ms. Sperrliste "SpamCop Block List" wird berprft   Die Adresse befindet sich nicht in der Sperrliste.   Weitere Details   Die IP-Adresse 62.2.148.162 wurde nicht in RBL gefunden. Verstrichene Zeit: 39 ms. Sperrliste "NJABL.ORG Block List" wird berprft   Die Adresse befindet sich nicht in der Sperrliste.   Weitere Details   Die IP-Adresse 62.2.148.162 wurde nicht in RBL gefunden. Verstrichene Zeit: 8717 ms. Sperrliste "SORBS Block List" wird berprft   Die Adresse befindet sich nicht in der Sperrliste.   Weitere Details   Die IP-Adresse 62.2.148.162 wurde nicht in RBL gefunden. Verstrichene Zeit: 91 ms. Sperrliste "MSRBL Combined Block List" wird berprft   Die Adresse befindet sich nicht in der Sperrliste.   Weitere Details   Die IP-Adresse 62.2.148.162 wurde nicht in RBL gefunden. Verstrichene Zeit: 53 ms. Sperrliste "UCEPROTECT Level 1 Block List" wird berprft   Die Adresse befindet sich nicht in der Sperrliste.   Weitere Details   Die IP-Adresse 62.2.148.162 wurde nicht in RBL gefunden. Verstrichene Zeit: 206 ms.

	Sender ID wird berprft.
	Fehler bei der berprfung der Sender ID

(error testing sender ID, other tests OK)

IMAP wird fr Benutzer 'snnet\admin' auf Host 'snlemon.snnet.ch:993:SSL' getestet.
	Fehler beim IMAP-Test.
	Weitere Details   Verstrichene Zeit: 21023 ms.
	Testschritte   Es wird versucht, den Hostnamen snlemon.snnet.ch im DNS aufzulsen.   Der Hostname wurde erfolgreich aufgelst.   Weitere Details   Zurckgegebene IP-Adressen: 62.2.148.162, 2002:3e02:94a2::3e02:94a2 Verstrichene Zeit: 8 ms. Es wird getestet, ob TCP-Port 993 auf Host snlemon.snnet.ch berwacht wird/geffnet ist.   Der angegebene Port ist blockiert, wird nicht berwacht oder sendet nicht die erwartete Antwort

 (error TCP port 993)

Command set-outlookprovider not recognized by EMS.

Would like to add that the old Cert, containing the hostname, is still valid and could probably be used but would need to get advice how to do it since EMC cannot be accessed. Thank you.

Sounds like you are not using split DNS. What I don't understand though is that you should be able to bypass cert warning and still access ecp. I can access my ecp using these although they both produce cert errors: https://Netbios_Name/ecp and https://Internal_IP/ecp

The best way to go is to setup an internal DNS record that points your public URL to your internal Mail server IP (the split DNS).  So for example if you have https://webmail.mycompany.org/owa out on the internet then you need an internal DNS record to point webmail.mycompany.org to the internal IP of your mail server.  Then whether someone is internal or external they use the same URL (it just resolves differently based on whether internal or external).  That way the cert you have already covers you in both circumstances.

You would then need to fix the virtual directory URLs so that internally and externally they are the same.

You might also try from the server itself to access ecp with:

https://netbios_name/ecp?ExchClientVer=15

• Edited by MnM Show 11 hours 30 minutes ago

Thank you. You're right, split DNS is not used.

Have tested https://62.2.148.162/ecp and https://snlemon/ecp and https://snlemon/ecp?ExchClientVer=15 and always get "There is a problem with this website's security certificate". Did that on the mailserver.

The split DNS suggestion is not quite clear: Do you mean a DNS resource record stating "mail.snnet.ch Alias(Cname) 62.2.148.162" ? With the latter the IP address of the mailserver or another resource type?

Sounds like you are not using split DNS. What I don't understand though is that you should be able to bypass cert warning and still access ecp. I can access my ecp using these although they both produce cert errors: https://Netbios_Name/ecp and https://Internal_IP/ecp

The best way to go is to setup an internal DNS record that points your public URL to your internal Mail server IP (the split DNS).  So for example if you have https://webmail.mycompany.org/owa out on the internet then you need an internal DNS record to point webmail.mycompany.org to the internal IP of your mail server.  Then whether someone is internal or external they use the same URL (it just resolves differently based on whether internal or external).  That way the cert you have already covers you in both circumstances.

You would then need to fix the virtual directory URLs so that internally and externally they are the same.

You might also try from the server itself to access ecp with:

https://netbios_name/ecp?ExchClientVer=15

• Edited by MnM Show Wednesday, March 25, 2015 7:54 PM

Hi Marcel,

Please make sure the certificate specified in your Default Web Site and Exchange Back End are the same certificate which is pointed to your new certificate which has mail.domain.ch. Please check the following points in IIS Manager:

1. Open IIS Manager in Exchange 2013.

2. Click on your server, double click Server Certificate and check the certificate Details for mail.domain.ch Thumbprint.

3. Click on Sites > Default Web Site. In right column you will see Binding option, click on it.

4. Choose HTTPS and click Edit. In SSL certificate box, click View and make sure the Thumbprint in the certificate Details is pointed to mail.domain.ch Thumbprint.

5.Click the Exchange Back End, please do the same steps and make sure the certificate is the same with mail.domain.ch Thumbprint.

6. After all settings, please restart IIS service by running iisreset /noforce from a command prompt window.

Regards,

Hi Winnie,

Thank you very much for your suggestions. Unfortunatelythe situation is a bit more complex. Here the current state and the changes and the result:

Server Certificates on mailserver (SNLEMON):

1) Microsoft Exchange issued to snlemon issued by snlemon expiration 1/10/2015 thumbprint

1c 41 07 8b 23 de 34 07 f0 61 9a ad 2d 7e 7e ff 91 c4 de a1

2) Microsoft Exchange Server Auth Certificate issued to Microsoft Exchange Server Auth Certificate issued by Microsoft Exchange Server Auth Certificate expiration 12/15/2017 thumbprint

b8 c9 5e 45 dc b2 ca b0 ee 46 d0 95 a2 cc 1e 71 3a 14 6a 3a

3) SNCERT25134 issued to snnet.ch issued by Comodo RSA Domain Validation Secure Server CA expiration 3/9/2018 thumbprint

64 51 d6 f4 9e 1c c8 0e c5 eb a9 de cc 44 e4 b5 61 61 79 2c

4) SNCERT25134 issued to snnet.ch issued by Comodo SSL CA 4/26/2015 thumbprint

34 cf ff 53 71 bd b7 bb fe 48 12 00 13 b4 ec ce 21 2f 0b ec

5) SNCERT25134 issued to snnet.ch issued by Comodo RSA Domain Validation Secure Server CA expiration 3/9/2018 thumbprint

26 d1 25 1a 4c 41 f2 82 a8 32 6f ed 0c 80 40 e8 73 f9 10 ff

There are 4 Websites: Default Web Site, Exchange Back End, Secondary Website and snnet.ch. Command get-website on EMS shows snnet.ch and secondary website in stopped condition, all others started.

Default website https bindings: no hostname, port 443, IP address 62.2.148.162 SSL Certificate SNCERT25134 thumbprint:

64 51 d6 f4 9e 1c c8 0e c5 eb a9 de cc 44 e4 b5 61 61 79 2c

Exchange Back End https binding: no hostname, port 444, IP Address * SSL Certificate Microsoft Exchange thumbprint

1c 41 07 8b 23 de 34 07 f0 61 9a ad 2d 7e 7e ff 91 c4 de a1

What I did: Left Back End https bindings and Cert, changed Default Web Site https bindings to no hostname, port 443 IP address * and the SSL Cert to Microsoft Exchange. And then iisreset /noforce (successful).

Still cannot connect to the Exchange server with outlook and ECP still shows unexpected error. What is worong?

Hi Winnie,

In the meantime I've tried all 5 Certs in Default Website but none allows to connect to ECP.

Marcel

Dear Winnie,

Update: There is success: With Cert No. 5 both in Default Web Server and in Exchange Back End Microsoft Outlook can connect. Both https entries are now: no host name, port 443/444, IP address 62.2.148.162.

But connection to ECP still yields in "Unexpected Error* (URL https://snlemon.snnet.ch/ecp).

Marcel

Since ECP is not working I plan to implement https://support.microsoft.com/en-us/kb/940726. But as already mentioned: the EMS command "Set-ClientAccessServer" "is not recognized as the name of a cmdlet" etc. Also not recognized are AutoDiscoverServiceInternalUri, Get-ManagementScope, Get-ManagementRole etc. Do you have an explanation for this strange behavior by EMSr?