Showing posts with label OWA. Show all posts
Showing posts with label OWA. Show all posts

07 December 2015

Add Private computer and Lite version options back to OWA

When searching how to brand the OWA page with a server name, i came across this post by  Arjan Mensch.

It describes how to add the Lite OWA version and the Private computer options back in to OWA 2013 (and maybe even 2016, but i'm not able to test this).

As you may remember from Exchange 2010, there was an option to choose your privacy mode for the session:

  • This is a public or shared computer
  • This is a private computer
  • Use Outlook Web App Light























Choosing between public or shared means different timeout values for the OWA session.

To bring the public private option back to OWA run in the Exchange powerShell:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -LogonPagePublicPrivateSelectionEnabled $true

To bring back the Light version of OWA:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -LogonPageLightSelectionEnabled $true

To enable both the "private public" and "Lite" option for several servers in a nice onliner:
Get-OwaVirtualDirectory | Where-Object {$_.owaversion -eq "Exchange2013"} | Set-OwaVirtualDirectory -LogonPagePublicPrivateSelectionEnabled $true -LogonPageLightSelectionEnabled $true


After running these command-lets you need to restart IIS.
To do this for all servers you can run this:
$servers = "server1","server2","server3","server4","server5","server6"
foreach ($server in $servers) 
{
restart-service -servicename "w3svc"
}

Brand OWA 2013 logon page

Just like in Exchange 2007 and 2010, the Outlook web app page can be customized to your needs.

See my previous post about this here.

In my organization we use 6 multi role Exchange 2013 servers, and when logging on to OWA you can't quickly see on which server you ended up.

This can be edited fairly quickly, but keep in mind that all these changes are undone when updating the Exchange systems with a cumulative update (CU).

First you need to go to the following location:
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
In there you will find a file called "logon.aspx", open it in your editor of choice.

For me that's Notepad++, and on line 272 add the following line:

<p><span style="color: #FFFFFF;">SERVERNAME</span></p>

This will add your servername in white text. So if you want to see it you'll have to select the entire logon page by pressing CTRL + a, then you will see the servername.



Important Note: These edits are overwritten anytime an Exchange Server update is applied to the CAS servers.
This is because every update includes a complete reinstallation of the Exchange binaries, and the logon.aspx file you edited will be overwritten.


Typically, the logon.aspx page rarely changes, so you can usually make a copy of it after you've made your edits and copy it back after the update. However, there are no guarantees that the file will not be changed by an update. If so, you will need to re-edit the logon.aspx file.

After each installation of a cumulative update for Exchange 2013, remember to execute both the UpdateCas.ps1 and UpdateConfigFiles.ps1 Windows PowerShell scripts.
It will save you a lot of trouble, troubleshooting errors with OWA and ECP.

11 November 2015

Skype for Business 2015, Lync 2010 and Lync 2013 IM integration into Exchange 2013 OWA

Update - 27-10-2016 - Added step 3.

We're migrating to Exchange 2013 at my company, and one of the things on my todo list was get Lync integrated into Exchange 2013 OWA.

After finding this great blog post from Oliver Moazzezi it worked at the first try.
I found this article at Technet and thought it was even more clear, especially for Skype for Business 2015.

There were a couple of things that could use some clarification so here is a little rewrite:

Exchange 2013 has two roles. The Front End proxy, and the Back End. The Back End co-locates all roles which are: Mailbox, Client Access, Hub Transport and Unified Messaging.
In Exchange 2010 you configured the IM integration entirely on the server that had the Client Access role. This could be a standalone server all co-located role server depending on the infrastructure needed. This was a config file at Exchange 2010 RTM and later moved to Powershell and settings on OWA virtual directories with SP1+.
In Exchange 2013 configuration is necessary on both the Front End and Back End roles. Again this can be co-located or standalone. I will treat them as separated for ease of understanding here.
Exchange 2013 Front Ends

1.    Perform in Powershell “Get-OWAVirtualDirectory”, you can use “Get-OWAVirtualDirectory –identity “servername\owa (default web site)” | select inst*” to immediately get the necessary information.



2. You will, if familiar with IM integration in Exchange 2010, be immediately at home here. However for IM integration in Exchange 2013 we only set two of the above four values. The values are ‘InstantMessagingEnabled’ and ‘InstantMessagingType’. We leave both ‘InstantMessagingCertificateThumbprint’ and ‘InstantMessagingServerName’ blank. This is very important as it actually does break the integration between Lync 2010 and Exchange 2013.

We can set these values with the following command:  
“Set-OwaVirtualDirectory –identity “servername\owa (default web site)” –InstantMessagingEnabled $true –InstantMessagingType OCS”
(Ignore the yellow text in my example below – I’m running the command to show you but as I’ve already set these attributes it’s telling me no settings have been modified)


3. Set the default mailbox policy to allow IM:

Set-OwaMailboxPolicy -Identity "Default" -InstantMessagingEnabled $True -InstantMessagingType "OCS"

4 . Perform the above command against ALL your Exchange 2013 Front End servers in your associated sites that need IM integration.

Exchange 2013 Back ends

5. Once this has been set we need to configure certificates. But the certificate configuration is on our Back End Exchange 2013 Servers. Browse to your Back End Servers and generate a new Certificate using New-ExchangeCertificate against the internal CA that Lync uses. I recommend this TechNet article for Cert creation: http://technet.microsoft.com/en-us/library/aa998327.aspx

Use the following two commands:
$Data = New-ExchangeCertificate –GenerateRequest –SubjectName “CN=servername.domain.lan” –DomainName “servername.domain.lan” –PrivateKeyExportable $true –FriendlyName “Easy title to see the purpose of this certififcate”

Then:

Set-Content –Path “C:\Temp\Servername.req” –Value $Data


6. Once this is done we need to complete the signing request against your internal certificate authority. I have used the web request of our SubOrdinate for this example. Use the same internal CA as what you used for SSL procurement for your Lync platform!



Save the signing request.
7. We now need to complete the signing request using Import-ExchangeCertificate. Information on this cmdlet is available here: http://technet.microsoft.com/en-us/library/bb124424.aspx


“Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path ‘C:\Temp\Servername.cer’ -Encoding byte -ReadCount 0))




The certificate is now installed.
After importing the certificate you will see the thumbprint in the result screen as seen above.

--Copy this thumbprint now, you need it later in the web.config file--
Ensure you do this for all Exchange 2013 Back End Servers.
  

8. We are now in a place where all our Exchange 2013 Front End Servers have had the necessary configuration via Powershell and ‘Set-OWAVirtualDirectory’, and we have installed Certificates on all our Exchange 2013 Back End servers. We now need to edit a web config file on each Exchange 2013 Back End.The file we want to modify is the web.config file in the following location “x:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa”. Where x is the drive you installed too.


9.     Open the Web Config file and perform a search for “</appsettings>”. This takes you to the end of all App Settings configuration. Add these three lines in:

    <!-- Lync IM -->

    <add key="IMCertificateThumbprint" value="Enter Thumbprint here!" />
      <add key="IMServerName" value="FQDN of Lync Pool or Director Pool" />

To get the Lync FQDN Pool name:

Get-CsPool | fl fqdn
   You can see I have commented this out to explain the change I am making.


It is important to note that the thumbprint you enter in each web.config file is the thumbprint of the Certificate you have created on each Back End server.

10. Once you have performed this on all Back Ends we need to open the Lync Topology Builder and enter each Back End as a Trusted Application

Add each Exchange 2013 Back End server separately, matching the FQDN of the server and the certificate published for the Back End as the Trusted Application. Add all required Exchange 2013 Back Ends. You can also do this in a Lync PowerShell:

New-CsTrustedApplicationPool -Identity Mailboxserver.domain.com -Registrar lyncpoolname.domain.com -Site 1 -RequiresReplication $False


11.   Once created you can edit them and remove ‘Enable replication of configuration data to this pool’ as this is not needed for Lync IM integration.

12. Once all have been added Publish the Topology.
13.   We now need to open a Lync Powershell session and perform the following:

New-CsTrustedApplication –ApplicationID “Server Name” –TrustedApplicationPoolFqdn “FQDN of Exchange 2013 Back End server” –Port ‘desired port number’

Set the ApplicationID as the server name for easy reference. Set the TrustedApplicationPoolFQDN as the FQDN of the Exchange 2013 Back End you are adding. Add a port number that isn’t in use. I used 5199.



14. Once this is done ensure you repeat it for every Exchange 2013 Back End server that you need and indeed published in the Topology Builder in step 11. and 12.
15. And the last thing: Enable-CsTopology
In case it's not working as expected we may need to do the following two things to get Lync IM integration working.

The first is to recycle the MSExchangeOWAAppPool on each Exchange 2013 Back End.

This needs to be done only if IM integration is not working in OWA.

The second is to restart IIS on each Exchange 2013 Front End server.
This needs to be done only if IM integration is not working in OWA.

16. Open OWA. You should now be able to sign in and see this:




The first thing you’ll notice over Exchange 2010 OWA integration is that the contact list is not shown on the left pane anymore. You have to get it from the People Hub.



If you aren't seeing the above then you may have an OWA Mailbox Policy that isn't allowing IM. Perform in Powershell: Get-OWAMailboxPolicy to confirm against the affected users.

In the event this is the issue, use:

"Set-OWAMailboxPolicy -identity 'OWAMailboxPolicy' -InstantMessagingType OCS"

06 November 2013

Outlook web access opens in "Light mode" by default on Windows 8.1

If you upgraded to Windows 8.1 and tried to access Outlook Web App with the new Internet Explorer 11, you probably noticed that the “Use the light version of Outlook Web App” checkbox is checked and disabled on the login page:

owa-light

That means that IE11 is willing to render only the basic version of OWA which was originally designed to target legacy browsers. This is quite embarassing, because IE11 is a really modern browser even in the preview!
The solution is to force IE to render OWA in compatibility mode. You can add the site to the compatibility list in the Tools –> Compatibility View Settings dialog:

compatibility-view-settings

This didn’t solve my problem, because only top-level domains can be added to this list, but I could take the advantage of the fact that according to the first checkbox, intranet sites are by default rendered in compatibility view. So I added my OWA URL to the list of sites in the Intranet Zone in the Tools –> Internet Options –> Security –> Local intranet –> Sites –> Advanced dialog.
According to some forum posts, the same issue arises with Office 365 and some popular websites like GitHub as well.

Source

11 February 2013

Exchange 2010 SP1 Password Reset Tool

Now that SP1 for Exchange 2010 is released, it is time to start exploring some of the new features. The first in line is the newly release password reset tool (this was also included in Exchange 2007 SP3). 
This has been a long awaited feature since OWA has been in use. For users that primarily use OWA for email access or are primarily remote access users, administrators have always struggled with resetting user’s password that will force users to change at first logon. Also users have struggled with remembering to reset their passwords through OWA before the password expired since their was no warning integrated with OWA.
The following is the setting within the user account that forces the user to change their password at next logon:
PW-user acct-markup
When a user tried to login to OWA with an expired password or configured to change their password at next logon, the user would see the following error: “The user name or password you entered isn’t correct. Try entering it again”
pw-OWA before-markup
The Password Reset Tool feature is not active by default. To activate this feature within Exchange 2010 SP1 (or Exchange 2007 SP3), all that is needed is one registry key:
HKLM\SYSTEM\CurrentControlSet\Services\MSExchange OWA
Create DWORD: ChangeExpiredPasswordEnabled with value: 1
PW-registry
After creating the registry entry, an IISReset must be performed. Now under the same scenario, if a user is configured to change their password at next logon or if their password has expired, the user will see the new message: “Your password has expired and you need to change it before you sign in to Outlook Web App.”
pw-OWA after-markup
Now the user can change their password before logging into OWA:
pw-OWA after3
But that is not all…If a user’s password is set to expire within 14 days, a user will see a warning while they are logged into OWA and will have the option to reset their password:
pw-OWA warning-markup


Source

08 February 2013

Brand OWA 2007 and 2010 with the Server Name

How to Brand OWA 2007, 2010 and 2013 with the Server Name
If your Exchange 2007 or Exchange 2010 and 2013 environment includes more that one CAS server, it's sometimes helpful to know which one a client is connecting to.  Environments with more that one CAS usually use some form of hardware or software load balancing, making it difficult to troubleshoot OWA issues.

A relatively easy way to do this is to brand each CAS server's OWA logon page with the server name.  This way, end-users are able to provide the server name if they run into problems.

For Exchange 2007, navigate to C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\auth folder and open the logon.aspx file using Notepad.

Add either of the two edits shown in the screenshot below:


Adding the server name as highlighted above in red will visibly add the server name to the logon screen, as shown below:



Adding the server name as highlighted above in blue will add the server name "invisibly" below the logon screen.  To view the server name, click anywhere on the screen and press CTRL-A to select all.  You can then see the server name, as shown below:


For Exchange 2010, navigate to the C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth folder and open the logon.aspx file using Notepad.


Add the server name, as shown in the screenshot below:


This will add the server name to the logon screen, as shown below:


For Exchange 2013, navigate to the C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth folder and open the logon.aspx file using Notepad. In my example i used Notepad++ so you can see the line number.
On line 272 add: <p><span style="color: #ffffff;">servername</span></p>



Edit:
I added a personal touch to the 2010 option, at the very end of the logon.aspx page add the line:
<p><span style="color: #ffffff;">SERVERNAME</span></p>
This line will be invisible on the loginpage until you select ctrl + a.



Important Note: These edits are overwritten anytime an Exchange Server update is applied to the CAS servers.  This is because every update includes a complete reinstallation of the Exchange binaries, and the logon.aspx file you edited will be overwritten.

Typically, the logon.aspx page rarely changes, so you can usually make a copy of it after you've made your edits and copy it back after the update.  However, there are no guarantees that the file will not be changed by an update.  If so, you will need to re-edit the logon.aspx file.

18 November 2012

How to add a "Sign In Again" button to the Exchange 2010 OWA Sign Out page

By default when you click "Sign Out" in OWA 2010, Exchange 2010 directs you to a page that explains that you have successfully logged off from Outlook Web Access. The only button available, "Close Window", closes the existing browser window or tab. This article explains how to add a "Sign In Again" button to the logoff.aspx page, as shown below:


To add the Sign In Again button, follow these steps on each Exchange 2010 Client Access Server (CAS):
  • Logon to the CAS using a local Administrator account.
  • Using Windows Explorer, navigate to the %ProgramFiles%\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth folder and make a copy of the logoff.aspx file for backup.
  • Edit the logoff.aspx file using Notepad.
  • Use Find to search for the word logoffclose. In Exchange 2010 SP1 beta this will be line 123.
  • Insert the following code before this line, as a single line:
<input id="btnCls" type="submit" class="btn" title="Click here to sign in again." value="Sign In Again" onclick="window.navigate('/owa')" onmouseover="this.className='btnOnMseOvr'" onmouseout="this.className='btn'" onmousedown="this.className='btnOnMseDwn'">
  • Save the logoff.aspx file.
  • Copy the new logoff.aspx file to the same file path on all your 2010 CAS servers.
Remember that applying any Exchange 2010 Service Pack or Update Rollup to your CAS servers will overwrite the login changes you made, so create a copy of the edited logoff.aspx file to reapply the Logon Again button after the update. Also know that Service Packs and Update Rollups could possibly include changes to the logoff.aspx page, so you may need to follow these steps again to edit the new page included in the update.

Edit:

You can also add the following line to get the redirection automatically.

<--- start of the snippet-->
window.navigate('https://<servername>/owa')         
Owa.ExecCommand.execute(document, "ClearAuthenticationCache", false);
<--- end of the snippet-->

And for Firefox users:

<--- start of the snippet-->
window.location('https://<servername>/owa')         
Owa.ExecCommand.execute(document, "ClearAuthenticationCache", false);
<--- end of the snippet-->
 
Source