An insight into OWA Desktop by Messageware

In this article we will be looking at a product called OWA Desktop by Messageware.

What is OWA Desktop?

OWA Desktop provides users with an email client without having to install Microsoft Outlook.  It enhances the functionality of Outlook Web App 2010 or Outlook Web Access 2007 resolving many of the limitations which prevent OWA being used as a full blown email client.

OWA by itself has a number of problems when being used as an email client.  It runs in an internet browser and requires constant user interaction to ensure it does not sign the users session out.  Another problem with OWA is there is nothing stopping a user from accidentally closing the internet browser running their OWA session.

OWA Desktop is a light weight application written in Microsoft .Net Framework 3.5 SP1 which runs in the background on a users workstation providing them with a constant connection to Microsoft OWA.  It provides alerts, notifications, email, calendar and tasks access on the fly as you would get out of Microsoft Outlook all from an easy to use OWA Interface.

OWA Desktop runs on the following operating systems:

• Windows XP
• Windows Vista
• Windows 7
• Windows 8
• Windows Server 2003
• Windows Server 2008
• Windows Server 2008 R2
• Windows Server 2012

OWA Desktop currently supports the following version of Exchange:

Exchange 2007

Exchange 2010

Office 365

OWA Desktop utilises a combination of Exchange Web Services and Outlook Web App to interact with the Exchange 2007/2010 servers.  OWA Desktop will support Exchange 2013, however this is still in development.

When would you want to deploy OWA Desktop?

Not all users require programs such as word processors and spreadsheet applications to perform their daily job.  Some users may only require an email client and it doesnt make sense to deploy the entire Microsoft Office suite.  Microsoft Office is a serious investment which needs to be factored into any IT budget.  There is a gap which needs to be filled to provide companies a cheap alternative for a desktop email client.  Messageware have filled this much needed gap with OWA Desktop providing companies the ability to deploy an email client to users at a cost of around $1.50 EURO a user per month.  Pricing is subject to change and depends on the number of users licenses purchased but regardless it is a significant cost saving over the purchase of Microsoft Oulook.  To get a quote for your organisation contact SalesTeam@messageware.com.
Running OWA Desktop for end users provides additional cost savings other then just licensing.  It also provides a reduction in IT operational expenses.  Deploying Microsoft Office to users means that Microsoft Office needs to be maintained.  Administrators need to deploy critical security updates and patches to Microsoft Office to ensure security vulnerabilities in the application are not exposed.  Products such as Symantec Altiris, Microsoft System Center Configuration Manager (SCCM) or Windows Software Update Services (WSUS) must be put in place to maintain various industry security compliance's such as CIS or NIST to patch security vulnerabilities in Office when discovered.  When running OWA Desktop, all content displayed within OWA Desktop is generated from the Exchange server through OWA and Exchange EWS.  Administrators no longer need to worry about patching and maintaining Microsoft Office.

OWA Desktop In Action

OWA Desktop is very easy to configure, it supports autodiscover and only requires a few details to get started.

Once setup OWA Desktop sits in your system tray.  Any incoming emails, meeting requests or appointments popup in the bottom left the users screen as it would in Microsoft Outlook.  It remains logged in and will automatically reconnect should disruption to OWA services occur.  OWA Desktop can also be configured to automatically load with Windows to ensure users never miss an email.

When right clicking on OWA Desktop the application menu appears.  Users can open their inbox, calendar, tasks or compose a new email message at the click of a button.  Compared to the number of clicks required to open a new browser, login to OWA, and click the new compose button it makes utilising OWA as a desktop email client simple, easy and hassle free.



The following screenshot shows the Inbox screen of OWA Desktop.



The following screen shows composing a new email via OWA Desktop.

It is OWA as you know it, simple, fast, easy to use in a desktop environment!

Messageware Active Send

Another component of OWA Desktop which is installed seperately using a seperate MSI file is Messageware Active Send.  This incorporates the send to mail functionality of the Windows operating system with OWA associating OWA as an application.  When a user right clicks a file, navigates to Send To and selects Mail recipient, Messageware Active Send will automatically upload the file into Exchange 2010 OWA and open the file as an attachment to a new email message in OWA - very cool.  This also works with any "mailto:" hyperlinks which may appear within documents, email messages or web pages.




Deployment

Both OWA Desktop and Active Send are MSI files which can be deployed to workstations on mass through group policy software deployment or another application such as SCCM or Symanted Altiris.

Conclusion

OWA Desktop is a great low cost application for users who do not require the full Microsoft Office product suite.

RemoteApps do not appear in RD Web Access when configured to use the RD Broker

Whilst building a new RDS server farm I ran across a problem which had me stumped for a few hours.  When configuring RD Web Access you need to specify a source for the RemoteApps, either an RD Broker or a bunch of Session Hosts as per the following screenshot.

When I selected "An RD Connection Broker" and specified the name of the broker server, I did not get any RemoteApps appearing in my "RemoteApps Programs" tab.  However when I specified the name of a Remote Desktop Session Host, the applications on the session host appeared as selected.

After much troubleshooting the problem was identified.  On each RD Session host server there is a local group called "TS Web Access Computers" which documentation on TechNet says you must nest the computer accounts of any RD Session Hosts for which you want applications published.  However if you wish to publish applications through an RD Connection Broker, you must nest the RD Connection Broker computer account inside this group instead.  I found this a little unclear in the TechNet documentation.  After fixing up the group nesting the problem was resolved.

How to Add a Computer Account to a Restricted Group in Group Policy

There may be a time where you need to add a computer account to a number of local groups using Group Policy restricted groups.  Computer accounts however do not appear in the list of Object Types within Group Policy.

It is however possible, simply add the computer account without clicking Browse in this format:

DOMAIN\ComputerAccount$

As long as you add the dollar sign $ at the end of the computer account name, group policy will process it.

Open File - Security Warning with AppData Folder Redirection

In the process of setting up a new Windows Server 2008 R2 RDS server farm I came acros the following problem.  Whenever opening ANY application on my RD Session Hosts, I received the following "Open File - Security Warning".

After a bit of investigation I noticed that this error was occurring because I had a folder redirection policy in place for user Application Data.

To resolve the problem I noticed if I add the UNC path to where I'm redirecting the AppData to Internet Options, Local Intranet it resolves the problem.

This resolves the problem.  However I have multiple users I want to configure this setting for.  To configure this against multiple users using group policy, configure the following setting located under:

User Configuration --> Policies --> Windows Settings --> Internet Explorer Maintenance --> Security --> Security Zones and Content Ratings

Under Security Zones and Content Ratings, select Import the current security zones and privacy settings then click Modify Settings.

When the Internet Options dialog box opens, configure the Local intranet zone as above and save the settings.

Apply the group policy object to the users experiencing the problem.

Rename VMDK files in ESX

vSphere Client v4-v5 does not allow you to rename a VMDK file through datastore manager.  To rename a VMDK you must do this through management shell (SSH).

To enable the Shell through the GUI refer to the following screenshot:

Once in the shell, login through an SSH client such as Putty.

Navigate to the location in your VMware datastore in which you wish to rename the VMDK using the following command:
cd "/vmfs/volumes/Datastore Name/Directory Name/"

Use the following command to rename the virtual machine:
vmkfstools -E examplevm.vmdk examplevm-renamed.vmdk