How to Configure Public and Private Computer Settings in OWA 2013

This tip explains how to enable and configure the Public and Private computer settings in OWA 2013

The new Exchange 2013 Outlook Web App (OWA) logon page no longer allows users to select whether they are using a public or a private computer. By default, OWA 2013 assumes users are using a private computer the default timeout of 8 hours is used. This timeout specifies how long a user can be inactive before requiring him/her to sign in again.
The LogonPagePublicPrivateSelectionEnabled parameter in the Set-OWAVirtualDirectory cmdlet specifies whether the OWA sign-in page includes this private/public computer sign-in option. While by default this parameter is set to True in Exchange 2010, in 2013 it is set to False. To change this on server CAS1, simply run the following cmdlets:
Set-OwaVirtualDirectory “CAS1\owa (Default Web Site” -LogonPagePublicPrivateSelectionEnabled $True
IISreset /noforce
Similar to previous versions of Exchange, the default timeout for private computers is still 8 hours for public computers 15 minutes. You can change this by running the following cmdlets to create the necessary registry keys:
Set-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Services\MSExchange OWA” -Name PrivateTimeout -Value <timeout_minutes> -Type DWORD
Set-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Services\MSExchange OWA” -Name PublicTimeout -Value <timeout_minutes> -Type DWORD
IISreset /noforce






With Exchange 2013 administration moving to browser based, you can manage your Exchange 2013 environment from anywhere in the world, provided that they are published. How can we switch off access from outside the corporate network?

You can manage your 2013 environment with EAC internally by navigating to https://casserver/ecp or https://loadbalancedurl/ecp if you have an NLB or load balancer in place. Your external webmail url (https://mail.domain.com) can be used to access the EAC (with /ecp) from outside the corporate network.

You may have a valid reason to turn off access to EAC from outside the internal network and the good thing is that it can be turned off, without affecting your OWA or OWA Options. By default, the EAC access from outside the network is enabled.

You can turn it off by setting the AdminEnabled parameter of the ECP virtual directory to false.

It will take few minutes for Exchange to pickup the change. You can always run an iisreset to force the change. If you try accessing the EAC from outside now, you will receive a 404- website not found error, but your OWA and Options will continue to work.

Disable External Access of the Exchange Admin Center

With the introduction of Exchange 2013, Microsoft has removed the Exchange Management Console (EMC) and replaced it with the web-based Exchange Admin Center (EAC).  The EAC is a web based management console, which makes a lot of sense considering the large cloud implementations that Microsoft has with Office 365.  Moving from a thick client to a web client allows for more portability and management from anywhere.  The EAC is published through the ECP virtual directory on an Exchange 2013 CAS server.  The ECP also allows users to access their options in Outlook Web Access.  So if you've published OWA on the internet using Exchange 2013, then you probably have also published the EAC on the internet.  If that doesn't seem like a great idea to you, read past the break to see how it can be resolved.

Microsoft does provide a way to disable access to the EAC on a given CAS server.  The document for that is right here.  To summarize, you run a Set-EcpVirtualDirectory command and set the AdminEnabled property to False.  The ECP virtual directory will still allow users to access their options in OWA, but it will not allow access to the EAC.  Of course that means that you no longer have access to the EAC as well, so I hope you like PowerShell!  Microsoft recommends setting up an additional CAS server for EAC access only, if you don't have an internal only server already.  That seems a bit onerous and hamfisted to me.  There should be a more elegant solution, and lo and behold there is.  The solution is to add a second website to the CAS server and create an ECP and OWA virtual directory in that new website.

The steps for it are not necessarily obvious, so I have laid them out here:

1. Add a second IP address to the Exchange 2013 CAS server
2. Create the folder in this path %SystemDrive%\inetpub\wwwroot2
3. Create a second website in IIS pointed to the wwwroot2 folder and call it CustomEAC
4. Bind the website on ports 80 and 443 to the new IP address
5. Create a new ECP virtual directory using the command
   New-EcpVirtualDirectory -Server ServerName -WebSiteName "CustomEAC" -InternalUrl "https://eac.fqdn.com/ecp"
6. Create a new OWA virtual directory with this command
   New-OwaVirtualDirectory -Server ServerName -WebSiteName "CustomEAC" -InternalUrl "https://eac.fqdn.com/owa"
7. Set the original ECP virtual directory to restrict admin access with this command
   Set-ECPVirtualDirectory -Identity "ServerName\ecp (default web site)" -AdminEnabled $false
8. Edit the IP Address restrictions to only allow access to the EAC website from the internal subnets
9. Add a host record in DNS for the new EAC URL

If you are using a wildcard certificate then you can use the new eac.fqdn.com URL and not get a certificate error, otherwise you will get a certificate error when going to the website.  If you have an internal CA, you could always get an SSL certificate for that URL since it's for internal use only anyway.  The other option is to use non-standard ports for the second website, but continue to use the original IP Address.  For instance you could use 8080 and 8443 for the bindings, and still use the original URL.  That would avoid the certificate error issue as well.  The question becomes whether you want to remember the alternate ports you used, or the new URL.

I have tested this with Exchange 2013 SP1 and it seems to work without issue.  If you come across any problems, give me a holler in the comments!