
Microsoft have made a final release candidate version of Exchange 2010 available for public testing, available for 120-day trial from the Microsoft web site - http://technet.microsoft.com/en-gb/evalcenter/dd185495.aspx
In this article I shall look at the new features that Exchange 2010 will offer from a mobile perspective. For full details of the new features available, visit the Microsoft Exchange web site - http://www.microsoft.com/exchange/2010/en/us/overview.aspx
Installation
Whilst not suitable for production environments, should you want to install the release candidate yourself on a test server to run through the new features, the procedure I ran through was as follows:
You should now be ready to run the Exchange 2010 installation wizard. The options available during the installation process are fairly minimal: the server roles to be installed can be selected; if the Client Access Server role is selected, the external name of the web application can be defined:

Once complete, the new features available include the following.
Outlook Web Access (Webmail)

OWA is now referred to as the "Outlook Web App" and now provides full support for Firefox and Safari, meaning that Mac users can enjoy the same web experience as Windows users, and Windows users don’t have to use Internet Explorer if they don’t want to and still have access to right click context menus and advanced functionality:

The slight change in name is not merely an exercise in "marketing-eze", however. The Outlook Web App is precisely that: an application providing a similar level of functionality to that offered by the full Microsoft Office Outlook product, accessible from a wide range of web browsers.
Within OWA, users can search their whole mailbox for specific messages from within their web browser:

Users have access to a much wider range of options and settings within the Options view of OWA (which itself runs in a new web application within IIS on the Exchange server called the "Exchange Control Panel", or ECP), including the ability to edit their own contact information and have it updated directly to the Global Address List (GAL):



Exchange Administrators, when logging into OWA, have the option to view the settings for their own mailbox, another user's mailbox, or global settings pertaining to the organisation:


This view allows the administrator to perform routine tasks such as adding, removing and amending user accounts and distribution groups. When editing user accounts, administrators can edit such detail as contact information as well as primary email address details.
A new feature introduced in Exchange 2010 is "Mail Tips": this feature displays informational messages to users as they compose new mail messages. For example, if sending an email to a user who has their out of office enabled, when that recipient is added to the email message, you will be informed that the user is out of office - this may save you the bother of writing a long email only to have it bounced:

Similarly, you will be warned when sending an email to a user whose mailbox is full and cannot accept new mail; or when replying to an email on which you were originally BCC'd and also when when sending an email to a large distribution group (such as Global Everyone) - just in case you don't mean to tell the whole international company that someone's left their lights on in the car park!
Custom Mail Tips can also be defined on individual mailboxes by the administrator:

Full Exchange Administrators can define other administrative access roles and the scope of those roles' permissions:


This is useful for the administrator with a view to the ability to perform administrative tasks remotely via a web interface without the need to establish a separate VPN connection to the network, but also a means of providing access to the Exchange server's configuration pages to a helpdesk environment without providing access to the Exchange server itself or the full management console.
Users can add and remove access to shared address books and calendars via OWA, and arrange calendars in a "side-by-side" view for quick schedule checking:

Messages can be viewed in a "Conversation View", grouping messages in a single conversation thread together regardless of sender or date. Messages can also be forwarded as attachments to other messages:

I haven't tested this functionality myself yet, but if the Office Communicator Server (OCS) product is deployed within the organisation, Exchange 2010 OWA also features an instant messaging client application that integrates with OCS enabling users to quickly view the status of connected users and send and receive instant text messages directly from their web browser.
The features that users have access to within OWA can be enabled and disabled by the administrator via the "Segmentation" option that was introduced in Exchange 2007, but unlike 2007 where settings are global, in 2010 OWA profiles can be defined and applied on a per-user or per-group basis:

Windows Mobile 6.1

Exchange 2010 offers the same mailbox synchronisation and device management features as Exchange 2007 when used with Windows Mobile client devices running version 6.1 or later of the Windows Mobile operating system, and as with Exchange 2007, Server ActiveSync mailbox policies can be defined and applied on a per-user or per-group basis. These features include:


Windows Mobile 6.5
When Windows Mobile 6.5 devices start being released later this year, when used with Exchange 2010 the following additional features will also be available...allegedly, I hope to be able to test this very soon as sample units start coming in...so watch this space!
Importantly, Microsoft have also indicated that when Exchange 2010 is released, an updated version of the Outlook Mobile client will also be released which will provide all of the above functionality to devices running Windows Mobile 6.1, not just Windows Mobile 6.5
Unified Messaging
The Unified Messaging server role was introduced in Exchange 2007 and essentially enables your Exchange server to integrate with your VoIP telephone system, providing such functionality as the ability to have voicemail messages delivered to your Inbox as sound file attachments; the ability to dial into the phone system and 'speak' to Exchange - to say a person's name and be connected to their extension based on that person's contact information in the Global Address List; and the ability to dial into your mailbox and have new mail messages read back to you and voicemail messages played.
Exchange 2010 adds the ability for users to create personal auto-attendants for themselves via the OWA interface, creating rules for forwarding calls that are not answered. Voicemail messages can also be transcribed to text and delivered via email so that users don’t need to mess about opening WAV files in Windows Media Player on their device.
Administration
Besides the web administrative view described above, most of the administration of the Exchange server will be done via the Exchange Management Console, which thankfully has not changed significantly since Exchange 2007:


Microsoft have released a beta preview of the forthcoming Service Pack 1 update for Microsoft Exchange Server 2010, available for download here - http://go.microsoft.com/fwlink/?linkid=193120
The update includes several new archiving and mailbox search improvements which are beyond the scope of this blog to look into, but there are also several additions to the Outlook Web Access application and Exchange ActiveSync protocol which are worth a mention from a mobility perspective.
Performance of the web application in general has been improved, so that 'intensive' operations such as attaching a large file to an email will not cause your browser to appear to have hung, and the interface has been slightly re-worked to provide easy one-click access to common tasks:

Themes are also available to allow users to change the colour scheme of the application to suit their preference:

The Reading Pane can be moved or disabled:

And users can also now share their calendar to specific users (or anonymous users) directly from their web browser:

For users wanting to configure their device for POP or IMAP access to Exchange, should these services be enabled, the required settings are now available to users in the Options section:

For the administrator, the Exchange Control Panel site has also been improved, offering the ability to define Exchange ActiveSync policy settings:

Including the ability to define the default behaviour for handling new devices requesting Exchange ActiveSync access (ie whether they should be allowed, blocked or quarantined):

As well as editing and creating ActiveSync Mailbox policies via the web browser:




Support is also provided for web-ready viewing of IRM-protected documents.
The Exchange ActiveSync protocol itself has been updated in Service Pack 1, allowing for "tether-free IRM support", meaning that you can send IRM-protected email attachments without needing to connect the device to Outlook to set up the IRM protection.
Support is also included for "Send As", allowing users to send email messages from mailboxes other than their own.
Service Pack 1 for Exchange 2010 will be officially released later in the year.
For an overview of the features available in Exchange 2010 in general, read this article - http://blog.brightpointuk.co.uk/exchange-2010-features
When sending email to a Microsoft Exchange 2010 server, an undeliverable message is returned with an error code of SMTP 530
The default Exchange Receive Connector in the Hub Transport is not configured to support Anonymous email submission
Within the Exchange Management Console, browse to Server Configuration --> Hub Transport. Open the Properties of the default Receive Connector and click on the Permission Groups tab.
Tick the option to enable Anonymous users:


As Microsoft licenses the Exchange Server ActiveSync protocol to a wider range of device manufacturers and software companies including Apple, Nokia, Google, IBM, Dataviz among others, users can enjoy push-based mailbox synchronisation from a wider range of devices - which is good for the user, but potentially a nightmare for the network administrator who needs to ensure that all of these devices conform to corporate security and usage policies.
In this article I shall look at the different ways the administrator can control which devices can access Exchange mailbox data.
This article was written with considerable reference to similar articles featured on the MobilityDojo web site - http://mobilitydojo.net/2009/09/28/restricting-exchange-activesync-access/ and http://mobilitydojo.net/2009/10/27/restricting-exchange-activesync-acces...
My intent is largely to do it for myself, but also to hopefully convey the ideas discussed in more accessible terms.
There are a number of reasons why administrators may wish to restrict the type of client device employed by users to access the myriad of features offered by Exchange 2010:
Not least because some devices may not support corporate security policies including on-device encryption and strong password usage, or offer the ability to have elements of their hardware disabled remotely such as Bluetooth, or some devices may simply claim to support the Exchange ActiveSync protocol but may not yet have been fully tested to the administrator's satisfaction.
There are a number of ways of restricting access to an Internet-facing Exchange "Client Access Server" (CAS). These range from simply making it difficult unless you have the required information (SSL certificates, IP address) to using Exchange's own EAS policy capabilities, to barring all devices until specifically approved by the administrator.
Using Self-Signed SSL Certificates
SSL Certificates 'guarantee' the identity of a server by assigning a certificate to a server that comprises a digital hash value calculated by running the server's name through a complex algorithm. When requesting content from a server, the server presents its certificate, containing the hash value. Should the requesting machine perform a calculation on that hash value and come up with anything other than the expected server name, the connection is flagged as insecure. That is a massive simplification, but you get the idea. In order to be able to perform the calculation, the requesting server needs to be able to access the algorithm. If the server was assigned a root-trusted certificate, (by providers such as VeriSign, or Thawte), that algorithm is preinstalled on the device already. When using a self-signed certificate, your CA is not automatically trusted by the client device, so your root CA certificate (that contains the algorithm) needs to be installed onto devices manually before any certificates issued by that CA can be trusted. In a nutshell, in order to be able to trust a certificate, the root certificate of the CA that issued that certificate needs to be installed on the device.
Using self-issued certificates is normally a cost-saving measure: root-trusted certificates cost money and need to be regularly updated. But they can also offer a line of security purely based on the fact that some devices will not connect to servers that they do not trust - meaning that the administrator can control which devices have access by only installing the appropriate cert onto those devices they want to connect.
This only applies to certain devices, including Windows Mobile and Nokia Mail for Exchange clients: Android devices will warn the user about the nature of the certificate, but also offer an option to 'Continue Anyway'.
I have blogged previously about how to use a self-signed SSL certificate with Microsoft Exchange 2003 SP2 - http://blog.brightpointuk.co.uk/configuring-exchange-2003-activesync-usi...
Some customers have had trouble identifying, having run through this procedure, the appropriate root SSL certificate to export and install onto client devices. Microsoft have released a tool to help you correctly isolate and export the certificate to use - http://blog.brightpointuk.co.uk/microsoft-sslchainsaver
Using self-signed SSL certificates does mean that even approved devices may not be able to connect until the appropriate certificate is installed onto them - which may at the least require that the certificate be made available for download, or worse connected to a PC and the certificate copied to it via the appropriate desktop sync software - not ideal.
Using Exchange 2010's ActiveSync Device Policies
The device configuration policies in Exchange 2010 are unchanged from Exchange 2007: administrators can define, on a per-user or per-group basis, how client devices can be used, including:
(Click on images to view a larger version)
The extent to which client devices can have these policies applied to them varies and depends on the device or software manufacturer, but these built-in policies can be used to ensure that devices are used only in a manner that corresponds to corporate usage policies.
Using Exchange 2010 Powershell CommandLets
Exchange 2010 includes a collection of new CommandLets that can be run by the administrator at the PowerShell command line to define access control policies to the Exchange ActiveSync service, granting "Allow", "Block" and "Quarantine" access.
Quarantine
Should the administrator wish to quarantine all devices, preventing access to the Exchange ActiveSync service before explicitly approved by the administrator, this can be achieved by issuing the following command:
Set-ActiveSyncOrganizationSettings –DefaultAccessLevel Quarantine –AdminMailRecipients administrator@domain.com
This will cause any connection requests to be initially denied, and an emailing flagging the connection request to be sent to 'administrator@domain.com'. An example mail would look like this:
The user would see the following error message on their device:
The administrator, making note of the DeviceID in the email, can enable the device for access for the specific user with the following command:
Set-CASMailbox –Identity jamesl@domain.com –ActiveSyncAllowedDeviceIDs BC2DD3AE37CE0CB225D6D0BDBFECCC69
The user will then be informed that access has been granted:
Block and Allow
Quarantining all users and requiring that they be approved manually may constitute an unacceptable administrative overhead, and may not be required if certain device types are to be allowed access as a matter of course.
Access Policies can be defined based on specific client device properties, including:
Enabling the administrator to block, allow or quarantine at varying levels down to specific device models, types or operating systems.
Should you wish to allow all PocketPC devices, for example, you might issue a command of:
New-ActiveSyncDeviceAccessRule –QueryString PocketPC –Characteristic DeviceType –AccessLevel Quarantine
And to block all Nokia E71 devices, you might issues a command of:
New-ActiveSyncDeviceAccessRule –QueryString NokiaE71 –Characteristic DeviceModel –AccessLevel Block
Multiple rules can be defined, and rules operate on 'most-permissive' basis, so if you were to quarantine all devices, but explicitly allow Pocket PC devices, those devices would be allowed.
This does require that you know the correct details to enter. One way to do this is to allow a device to synchronise and then view its entry in Outlook Web Access:
Because Exchange ActiveSync uses the HTTP protocol to access Exchange, all access requests can be audited within the Exchange server's IIS web logs:
2009-11-14 19:34:04 192.168.0.100 OPTIONS /Microsoft-Server-ActiveSync/default.eas User=administrator&DeviceId=BC2DD3AE37CE0CB225D6D0BDBFECCC69&DeviceType=PocketPC& Log=LdapC21_LdapL48_Error: UserDisabledForSync_Budget:(D)Conn%3a1%2cAD%3a%24null%2f%24null%2f0%25%2cCAS %3a%24null%2f%24null%2f1%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null %2f%24null%2f0%25%2cFC%3a%24null%2f0%2cHash%3a51198184_ 443 domain\administrator 192.168.0.2 MSFT-PPC/5.2.1403 403 0 0 27633
In the above example access request:
For example.
IIS web logs can also be parsed automatically within the Exchange Management Powershell. Issuing the following command:
export-activesynclog -Filename:"C:\inetpub\logs\logfiles\w3svc1 \u_ex091115.log" -outputpath:"c:\temp\logs\"
(where you may need to substitute the path to the IIS log files and the specific log file name, and also ensure that the target output directory exists)
Will create several CSV files:
The UserAgents and Users files will list conveniently all access requests including device type and platform:
To display a list of configured policies, issue a Get command:
Get-ActiveSyncOrganizationSettings
It is also possible to create rules using Microsoft ISA server without having to mess about at the command line, but this is beyond the scope of this article - largely because I don't currently have an ISA server set up! Read the MobilityDojo web site for more details.
With the release of Exchange 2010 Service Pack 1, this process has been facilitated through the addition of Exchange ActiveSync Policy Rules in the Exchange Control Panel web interface.
If a user has attempted to synchronise with Exchange 2010 from their mobile device via Exchange ActiveSync, and you wish to create a policy for all other devices of that same type, you can now do so quickly and easily.
Log into Outlook Web Access with an administrative account and select the option to Manage My Organisation. Browse to Users & Groups. Edit the user with the device you wish to create a policy for:

Expand the Phone & Voice features options and select the option to Edit the ActiveSync policy:

All devices that the user has synchronised with Exchange will be listed. Select the option to Edit the policy for the target device:

Specify what action you wish to assign to the device type, be it "Allow", "Block" or "Quarantine". Save the new device access rule.
Once saved, the new rule will be listed:

From now on, any new devices that attempt to synchronise with Exchange will have the new device access rule applied to them (provided that they appear to Exchange as being the same device type):

Should a device be quarantined, as before you will receive notification that your device has been quarantined, as will the administrator, who will be able to unblock the device if desired, within the web interface:

When Exchange 2010 is released, it will include an enhanced Server ActiveSync capability that when used with a device running Windows Mobile 6.5, will include the ability to synchronise not only email, contacts, calendar entries and tasks, but also SMS test messages (http://blog.brightpointuk.co.uk/exchange-2010-features).

You will be to send SMS messages from within Exchange 2010 Outlook Web Access (OWA) in your web browser or Outlook 2010 on the desktop: select New --> Text Message, enter in a contact (which has a mobile number associated with it) or a specific telephone number, complete a suitable message and hit send. The message will be synced to your device's SMS Outbox and from there be sent as a text message. It will also appear in the Sent Items folder on both the device, and your Exchange mailbox.
Configuration
The setup procedure will be the same as with existing devices:


once you have entered the details of the Exchange Server as well as your account details, on the screen where you would normally be prompted to select the mailbox folders you wish to synchronise, in addition to the usual email, contacts calendar and tasks folders, you will now have the option of selecting Text Messages - only if you are connecting to a server running Exchange 2010:

Once connected, you will receive an automated email in your Inbox from the Exchange server itself informing you that the new feature has been enabled:

Usage
Once the feature has been enabled, the Text Messaging feature will show as being enabled within your account properties:

When composing a new message within Outlook Web Access (OWA), you will now have the option of selecting a Text Message:

The message window will indicate the number of characters that are available to be entered:

Once sent, the message will appear in the Sent Items folder:
