Broken ECP after removing IP address from IP Address and Domain Restrictions - Exchange 2013
Prior to this blog post existing ("Configuring Multiple OWA ECP Virtual Directories on the Exchange 2013 Client Access Server Role), I configured IP Address and Domain Restrictions in order to block access to the ECP to the outside world, and yes as stated, it stops users from accessing "Options" from within OWA. My problem is, is when I remove the IP address restrictions to enable access to Options from OWA, this breaks my access to the ECP altogether - I end up in a login loop to the ECP. Does anyone know how to fix this if the IP restrictions are taken out from the ECP virtual directory? OWA is still accessible to users, but "Options" results in a auto log out too. Cheers. 
July 7th, 2015 12:14am

Hi,

I understand that you are in a loop when click on the Options in OWA.

I would suggest to check that there is no IP Restrictions set on the following:

DWS, BE Website, OWA under DWS and BE Website, ECP under DWS and BE Website.

If all has been already checked, then you can try to set the authentication settings using Ex Management Shell. This is to overwrite the settings. I have seen such similar loop instances once (but not due to IP restrictions) and i had fixed it by setting the Authentication for ECP again.

Additionally you can try resetting the ECP Virtual Directory, but I would say this is a not recommended step by MS and you need to take backup of IIS before doing this step.

Karthick

Free Windows Admin Tool Kit Click here and download it now
July 7th, 2015 2:29am

Hey Karthick

Thanks for your response. I have actually set IP Address and Domain Restrictions and this has had the desired affect of restricting access to the ECP to the outside world. But this then breaks "options" for users when they use OWA - which I don't want. So I then went into the ECP virtual directory in IIS and removed the IP Address and Domain Restriction and this has prevented me from logging into ECP - it continuously says "username and password" are incorrect and they definitely are not. 

July 7th, 2015 2:33am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics