Configuring Exchange 2003 ActiveSync using a self-signed SSL certificate

If you are unwiling to fork out for a 'root-trusted' certificate from the likes of Thawte or VeriSign, and don't mind the inconvenience of manually installing client certificates onto your devices, then Exchange ActiveSync can be configured to use a self-issued certificate. The procedure is as follows.
NOTE - not all of these steps may be required on your Exchange installation, but this article was written using a clean install of Exchange 2003 and all steps were required to successfully synchronise from a WIndows Mobile 6.0 device.

Install Microsoft Certificate Services

If it isn’t installed already, install Microsoft Certificate Services via the Add/Remove Windows Components applet within the Control Panel on a server on the local network. Set the server as an Enterprise CA.

Request and Install a certificate for the Exchange server from the CA

Once installed, open a web browser on the Exchange Server and browse to http://(servername)/certsrv (where (servername) is the name of the server that has certificate services installed on it. The following window will be displayed:

Click on the option to Request a certificate, the following window will be displayed:

Click on the option to request a User Certificate. The following window will be displayed:

Click Submit. You will be prompted to confirm the action:

Click Yes. The following window will be displayed:

Click on the option to Install this certificate. Again, you will be prompted to confirm the action:

Click Yes. The certificate will now be installed on the server.

Configure IIS

Next IIS must be configured to use the certificate. Launch the IIS Manager. Right click on the Default Web Site and select Properties. Click on the Directory Security tab.

In the Secure Communications section, click on the Server Certificate button. The Server Certificate wizard will be displayed:

Click Next. The following window will be displayed:

Select the option to Assign an existing certificate and click Next. A list of available certificates will be displayed:

Select the certificate issued to the Exchange server and click Next. The following window will be displayed:

Select 443 as the SSL port to use. Click Next. Click Next again and then Finish. Back within the Directory Security tab, now click on the Edit button:

Tick the option to Require secure channel (SSL) and Require 128-bit encryption. Click OK.

Click on the Edit button in the Authentication and Access Control section:

Ensure that the option to use Integrated Windows authentication is ticked.

Click OK and then OK again to confirm the changes. Back within the IIS Manager, right click on the Exchange folder and select All Tasks → Save Configuration to a file:

Enter a name for the file, such as ‘ExchangeVDir’ and click OK:

IMPORTANT - if you have Forms-Based Authentication enabled on your OWA web site, you may need to disable it temporarily before exporting the configuration of the default web site. Read the Addendum section at the end of this article for more information.

Now right click on the Default Web Site folder and select New → Virtual Directory from File:

Click on the option to Browse, then select the ExchangeVDir.xml file you just created.
Click on Read File.
Select Exchange as the Location and click OK:

You will receive a warning that the name already exists, select the option to enter a new Alias and name it ‘Exchange-OMA’:

Click OK.

The new Exchange-OMA folder will now be listed. Right click on it and select Properties.
Click on the Directory Security tab. Within the Authentication and Access Control section click the Edit button. Ensure that only the following options are enabled:

Click OK. In the IP address and domain name restrictions section, click the Edit button:

Select the option to Deny access to all computers, then Add the IP address of the Exchange server. Click OK.

In the Secure Communications section, click the Edit button. Untick the option to require SSL:

Click OK and then OK again. Close the IIS Manager.

Edit the Registry

Now open Registry Editor on the Exchange Server. Browse to the following folder:

HKEY_Local_Machine\System\CurrentControlSet\Services\MasSync\Parameters

In the right hand pane, right click and select New → String Value. Enter a name of ExchangeVDir for the new string. Double click the entry to edit it:

In the Value data field, enter the name of the Virtual Directory you created earlier. Click OK.

Close Registry Editor.

Restart IIS

Open the Services snap-in and restart the IIS Admin service on the Exchange server. Select Yes to also restart all dependent services.

Once IIS has been restarted, close the Services snap-in.

Export the root certificate

On the Certificate Authority that issued the certificate to the Exchange server, open the Control Panel and double click Internet Options. NOTE - this guide assumes that you are using a Microsoft CA.

Click on the Content tab and then on the Certificates button. Click on the Trusted Root Certification Authorities tab:

Locate the trusted root certificate for your domain. It is vital that the certificate be trusted rather than be listed under any other tab. Select the certificate and click on the Export button.

The Export Certificate Wizard will be displayed, click Next:

Select the option to export the certificate in DER encoded binary X.509 (.CER) format and click Next.

Enter a name for the certificate and specify where you would like the file saved. Click Next, Finish and then OK.

Install the root certificate onto the client device

Now locate the .cer file created and copy it to your PDA via Microsoft ActiveSync to any folder on the device (for a Windows Mobile device), or using the appropriate synchronisation software for your device. Alternatively the file could also be saved to a memory card or transferred via Bluetooth.

On the PDA, open File Explorer and browse to the folder where you saved the certificate. Tap on the icon for the certificate and tap Yes to install it when prompted.

On a Windows Mobile device, tap on Start → Settings → System → Certificates → Root and verify that the certificate is listed.

You are now ready to use Server ActiveSync securely, using your own SSL certificate.

Addendum

If you use forms-based authentication on the OWA web site, it may be necessary to disable this feature before you export the IIS virtual directory to a file, then create the new virtual directory.
Once this has been done you can then re-enable forms-based authentication.
Having forms-based authentication enabled can cause the Windows Mobile client to fail to authenticate - you will be constantly prompted to enter your password despite the details being correct. Having it disabled on the specific virtual directory resolves the problem, but if it is enabled when you export the default configuration, that will be carried over to the new virtual directory you create.
Forms based authentication is enabled and disabled within the Exchange System Manager rather than within IIS. Browse to the Exchange Server --> Protocols --> HTTP and open the properties of the virtual Exchange HTTP Server:

For detailed troubleshooting steps on how to resolve Exchange ActiveSync issues, read this article - http://blog.brightpointuk.co.uk/troubleshooting-exchange-activesync

Enabling RPC via HTTP on a single Exchange 2003 server

“What is RPC over HTTPS, and why is enabling it on a single Exchange Server significant?” I hear you cry.

RPC over the HTTP(S) is the technical term for ‘Outlook Anywhere’ – the technology that allows you to access Exchange from an Outlook client via any Internet connection as if you were connected via the local network.

Outlook Anywhere is similar to the Server ActiveSync protocol used by Windows Mobile devices to access Exchange in that it is used to synchronise email, contacts and calendar with the client device, but whereas Server ActiveSync can only synchronise data with a specific user mailbox, Outlook Anywhere allows the user to use the full functionality of their Outlook client remotely – this includes accessing mailboxes other than their own (should they have permission to), public folders, everything they can do when connected locally in the office.

RPC stands for Remote Procedure Call. Whenever you perform an action in Outlook that requires a response from the Exchange server, Outlook sends a remote procedure call to the Exchange server and gets a response back.

What Outlook Anywhere does is to encrypt these remote procedure calls using a digital certificate and then send them to the Exchange server over the Internet, hence RPC over HTTPS.

Exchange 2007 can support Outlook Anywhere in a single-server deployment, but Exchange 2003 requires that Exchange be deployed in a 2-server topology called a ‘front-end’ / ‘back-end’ deployment. This is principally for security reasons: the ‘front-end’ server, because it is Internet-facing, sits in a DMZ environment and receives the encrypted request from the Outlook client. It then decrypts the request and sends it, unencrypted, over the local network to the ‘back-end’ Exchange server exactly as a local Outlook client would do. When the response is received from the back-end Exchange server, it is encrypted and then sent back to the client over the Internet.

It is possible to do all of this without encrypting the information, in which case it would be RPC over HTTP, but this guide assumes that you are using a certificate to encrypt information and I would not recommend not doing so.

It is important to note that Exchange 2007 can also be configured in this way should security be a concern, except that with Exchange 2007 the terminology has changed so that you no longer have ‘front-end’ and ‘back-end’ servers, instead you have different Exchange roles that can be applied in any topology you want – so you have ‘edge servers’ and ‘mailbox servers’ as well as ‘client access servers’ and ‘hub transport servers’.

The ‘role’ of an Exchange 2003 server is specified in the Exchange System Manager. Right click on the Exchange server and select Properties. On the General tab there is an option to specify ‘This is a Front End server’:

In a single-server deployment, if you try to select this option you will receive an error indicating that you cannot set a server as a front-end server if it is the only Exchange server in the organisation:

However it is possible. But it does involve editing the registry on the Exchange server. Therefore, you should not make any changes to your live Exchange environment unless you fully understand the potential ramifications of making any changes to the registry on your Exchange server.

To enable RPC over HTTP on your Exchange server, there are a number of steps you need to follow.

Install RPC over HTTP Proxy Service

You first need to install the RPC over HTTP proxy service. This is a component of the Windows Server operating system and is installed via the Add/Remove Windows Components applet within the Control Panel. It is located under Networking Services:

Configure authentication mechanism to RPC virtual directory within IIS Manager

Now launch the Internet Information Services (IIS) Manager applet. Locate the RPC virtual directory:

Right click on the virtual directory and select Properties.

Click on the Directory Security tab and then on the Edit button in the Authentication and Access Control section:

Untick the option to Enable Anonymous Access.

Tick the option to enable Basic Authentication, a warning message will be displayed click Yes to acknowledge it.

In the Default Domain field, click on the Select button and select the Domain that the Exchange server services:

Click OK.

NOTE – you have now basic authentication access to the Exchange server RPC directory, as mentioned previously this is acceptable if you are using a digital certificate to encrypt client-server communications, if you are not then any password information sent over the Internet could be intercepted.

Configure RPC virtual directory to require SSL communication within IIS Manager

Still within the Directory Security tab, click on the Edit button in the Secure Communications section:

Ensure that the option to Require Secure Channel (SSL) is ticked, as well as the option below it. Normally this option will be selected already if you use SSL with Outlook Web Access.

Configure RPC port access in the Registry

On the Exchange server, click on Start and select Run. Type in ‘regedt32.exe’ and click OK. This will launch Registry Editor.

Browse to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Verify that the Rpc/HTTP port is set to 6001 (it will be by default):

Now browse to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters

Verify that the HTTP Port is set to 6002 (it will be by default)

Also verify that the Rpc/HTTP NPSI Port is set to 6004 (it will be by default)

Now browse to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy

Double click on the ValidPorts entry, the following will be displayed:

Delete the contents of the field (exchange:100-5000), and replace it with the following:

(ServerNETBIOSName):6001-6002;:6001-6002;(ServerNetBIOSName):6004;(ServerFQDN):6004

where (ServerNETBIOSName) is the machine name of the Exchange server itself, and (ServerFQDN) is its external name (ie the name used by Outlook Web Access)

So my server would require the following entry:

exchange:6001-6002;exchange.oa-demo.co.uk:6001-6002;exchange:6004;exchange.oa-demo.co.uk:6004

If the Internal FQDN of the server is different from the External FQDN, then the entry needs to be longer. Suppose the NETBIOS name of the server is 'UKMAIL01', and the internal FQDN is 'UKMAIL01.oa-demo.co.uk', and the external name of the server is 'exchange.oa-demo.co.uk', then the entry would need to be:

UKMAIL01:6001-6002;UKMAIL01.oa-demo.co.uk:6001-6002;exchange.oa-demo.co.uk:6001-6002;
UKMAIL01:6004;UKMAIL01.oa-demo.co.uk:6004;exchange.oa-demo.co.uk:6004

You may need to adjust these settings, for example the internal FQDN may be UKMAIL01.oa-demo.local

Don't be afraid to experiment!

Exit Registry Editor.

Configure RPC over HTTP Topology in Exchange System Manager

Launch the Exchange System Manager.

Right click on the Exchange Server and select Properties.

Click on the RPC-HTTP tab, the following will be displayed:

Select the option to make the server a Back-End server. An error message will be displayed:

Click OK to acknowledge the error. Click OK again to save the changes to the configuration. A warning message will be displayed warning that the ports have not been configured correctly and be prompted to reconfigure them. Click CANCEL. You will be prompted to reboot the server.

Now reboot the Exchange Server.

Install the SSL certificate on the client PC

Before you can use Outlook to connect to the Exchange server via RCP over HTTPS, you will first need to install the correct SSL certificate onto the client PC to authenticate the certificate used by the Exchange server. This is only necessary if you are using a self-issued certificate. If you are using a root-trusted certificate on the Exchange server then ignore this step.

The certificate that needs to be installed on the client PC is not the certificate used by the RPC virtual directory on the Exchange server, but the root certificate of the Certificate Authority that issued the certificate to the RPC directory.

To locate this certificate, log into the server that has the Certificate Authority service installed on it. This may well be the Exchange server itself, it depends on how your network is deployed.

On the server that is acting as the CA, open the Control Panel and open Internet Options.

Click on the Security tab and the on the Certificates button.

Click on the Trusted Root Certification Authorities tab.

Locate the certificate issued by the CA and export it as a CER file. Copy this file to the client PC.

On the client PC double click the CER file to install it. Select the option to install it to the Trusted Root Certification Authorities folder.

Configure the Outlook Client

NOTE – to use Outlook via RPC over HTTPS you will require Outlook 2003 or later.

Create a new Outlook profile if required.

Select the option to create an Exchange Server account.

In the Server Name field enter the LOCAL address of the Exchange server (ie the machine name, or the NETBIOS name)

Enter your username.

DO NOT CLICK NEXT at this point, click on the More Setting button.

You may receive an error saying that the Exchange server cannot be contacted, click OK. A further window will be displayed asking you to verify the address of the Exchange server, click Cancel.

The More Settings window will now be displayed. Click on the Connection tab:

Tick the option to Connect to Microsoft Exchange using HTTP. Click on the Exchange Proxy Settings button:

Enter the external web address of the Exchange server (ie the address used for Outlook Web Access) in the fields as shown above. In the second text field, the ‘msstd’ is required!

Click OK, OK again, Next and then Finish.

Now launch Microsoft Outlook.

You will be prompted to enter your NT domain login credentials:

Enter your username in the form ‘DOMAIN\Username’

You will now be connected to the Exchange server:

In the immortal words of a popular 80s television show: "I love it when a plan comes together!"

Configuring remote file share access with Exchange 2007 OWA

One feature that Exchange 2007 introduced is the ability to access local file shares remotely via Outlook Web Access (OWA), enabling users to download any manner of document, spreadsheet, application, etc from any machine with Internet Explorer 6 or later installed on it without having to establish a VPN connection to the local network.

Configuring the Exchange Server

File share access is enabled and configured within the Exchange Management Console. Browse to Server Configuration --> Client Access --> Outlook Web Access and open the properties for the OWA site. Different permissions can be defined for users accessing the site from Public and Private computers:

Enable the feature by ticking the option to enable Windows File Shares. The types of files that users should have access to, or not, can be defined by Customizing direct file access:

File extension types can be defined explicitly:

The details of the file servers that should be available to OWA users are defined on the Remote File Servers tab:

Click on the Block button to define those servers that should NOT be accessible. Any servers that are not explicitly blocked are automatically allowed.

The Allow list does not define those file shares that should be accessible to users, rather it defines the hosts FROM which users are connecting that should be allowed to access file shares:

As users will typically be connecting from the Internet at large, if you want your users to have access to file shares from wherever they are, the Unknown Servers option should be set to Allow rather than block.

To enable users to enter only the NETBIOS name of the file server they wish to access rather than its FQDN (Fully Qualified Domain Name), the Domain Suffix configuration allows the administrator to add any suffixes (eg 'domain.com') that should be automatically appended to any server names users enter within OWA:

NOTE - the Exchange Server should be able to resolve these domains via DNS.

Verify that the file share configured on the remote file server is configured with the correct user access permissions - ie, those users that wish to access the share via OWA won't be able to if they are not able to locally via the LAN.

Accessing the share via Outlook Web Access

Log into Outlook Web Access using Internet Explorer - the file share feature is not available from Firefox (although from looking at the Beta it looks like this is resolved in Exchange 2010). If the administrator configured different permissions for 'private' and 'public' computers, be sure to select the correct login option.
Once logged in, click on the Documents link in the bottom left-hand corner:

Select the option to Open Location:

Type in the server and share address in the form "\\server1\share"

A list of available files will be displayed:

Selecting the file will allow you to open it or save it to disk:

You can also view the file share within Windows Explorer, effectively allowing you to work from the folder as if you had mapped a drive to the share directly.
Links to files or shares contained within email messages can be selected directly (provided that they are in the correct format including the full path to the server share)

Access to remote file shares is also possible from Windows Mobile devices, provided that they are running version 6 or later of the Windows Mobile operating system. For more information on configuring this feature read this article HERE.

Configuring remote file share access with Exchange 2007 Server ActiveSync

Exchange 2007 introduced the ability to access file shares on the local network remotely either from a PC web browser via Outlook Web Access (OWA) or directly from your Windows Mobile device without the need to first establish a VPN connection.

For details on how to configure Outlook Web Access, read this article HERE.

Configuring Exchange

File share access must be enabled on the Exchange Server within the Server ActiveSync mailbox policy. This is done within the Exchange Management Console, browse to Organisation Configuration --> Client Access:

Ensure that the option to enable Windows File Shares is ticked.

Specific shares can be defined within Server Configuration --> Client Access:

The details of the file servers that should be available to OWA users are defined on the Remote File Servers tab. Click on the Block button to define those servers that should NOT be accessible. Any servers that are not explicitly blocked are automatically allowed.

The Allow list does not define those file shares that should be accessible to users, rather it defines the hosts FROM which users are connecting that should be allowed to access file shares:

As users will typically be connecting from the Internet at large, if you want your users to have access to file shares from wherever they are, the Unknown Servers option should be set to Allow rather than block.

To enable users to enter only the NETBIOS name of the file server they wish to access rather than its FQDN (Fully Qualified Domain Name), the Domain Suffix configuration allows the administrator to add any suffixes (eg 'domain.com') that should be automatically appended to any server names users enter on their device:

NOTE - the Exchange Server should be able to resolve these domains via DNS.

Verify that the file share configured on the remote file server is configured with the correct user access permissions - ie, those users that wish to access the share from their PDA won't be able to if they are not able to locally via the LAN.

Accessing files from the Windows Mobile client

NOTE - only devices running Windows Mobile 6 or later support this feature.

Because the Windows File Share access feature uses the Server ActiveSync protocol, the Windows Mobile client must be correctly configured for Server ActiveSync and have synchronised at least once successfully with the Exchange Server.

Files can be accessed either from within Internet Explorer or directly from the File Explorer application by entering a path to the remote file share in the form \\server\share\filename.xxx
Links to files contained within email messages can be clicked on directly, provided that they are in the correct format.

NOTE - unlike Outlook Web Access which allows users to access the share itself and be displayed a list of available files within that share, Windows Mobile devices must request the specific file itself that is to be accessed.

Enabling RPC via HTTP on Exchange 2007

RPC over the HTTP(S) is the technical term for ‘Outlook Anywhere’ – the technology that allows you to access Exchange from an Outlook client via any Internet connection as if you were connected via the local network.

Outlook Anywhere is similar to the Server ActiveSync protocol used by Windows Mobile devices to access Exchange in that it is used to synchronise email, contacts and calendar with the client device, but whereas Server ActiveSync can only synchronise data with a specific user mailbox, Outlook Anywhere allows the user to use the full functionality of their Outlook client remotely – this includes accessing mailboxes other than their own (should they have permission to), public folders, everything they can do when connected locally in the office.

RPC stands for Remote Procedure Call. Whenever you perform an action in Outlook that requires a response from the Exchange server, Outlook sends a remote procedure call to the Exchange server and gets a response back.

What Outlook Anywhere does is to encrypt these remote procedure calls using a digital certificate and then send them to the Exchange server over the Internet, hence RPC over HTTPS.

Install RPC over HTTP Proxy Service

You first need to install the RPC over HTTP proxy service. This is a component of the Windows Server operating system and is installed via the Add/Remove Windows Components applet within the Control Panel. It is located under Networking Services (assuming you are running Server 2003 rather than Server 2008):

Enable Outlook Anywhere

The Outlook Anywhere function is enabled within the Exchange Management Console. Expand the Server Configuration container and select the Client Access folder:

Select the option to Enable Outlook Anywhere – a wizard will be displayed:

Enter the external name of the server and configure the authentication options to be used.

Install the SSL certificate on the client PC

Before you can use Outlook to connect to the Exchange server via RCP over HTTPS, you will first need to install the correct SSL certificate onto the client PC to authenticate the certificate used by the Exchange server. This is only necessary if you are using a self-issued certificate. If you are using a root-trusted certificate on the Exchange server then ignore this step.

The certificate that needs to be installed on the client PC is not the certificate used by the RPC virtual directory on the Exchange server, but the root certificate of the Certificate Authority that issued the certificate to the RPC directory.

To locate this certificate, log into the server that has the Certificate Authority service installed on it. This may well be the Exchange server itself, it depends on how your network is deployed.

On the server that is acting as the CA, open the Control Panel and open Internet Options.

Click on the Security tab and the on the Certificates button.

Click on the Trusted Root Certification Authorities tab.

Locate the certificate issued by the CA and export it as a CER file. Copy this file to the client PC.

On the client PC double click the CER file to install it. Select the option to install it to the Trusted Root Certification Authorities folder.

Configure the Outlook Client

NOTE – to use Outlook via RPC over HTTPS you will require Outlook 2003 or later.

Create a new Outlook profile if required.

Select the option to create an Exchange Server account.

In the Server Name field enter the LOCAL address of the Exchange server (ie the machine name, or the NETBIOS name)

Enter your username.

DO NOT CLICK NEXT at this point, click on the More Setting button.

You may receive an error saying that the Exchange server cannot be contacted, click OK. A further window will be displayed asking you to verify the address of the Exchange server, click Cancel.

The More Settings window will now be displayed. Click on the Connection tab:

Tick the option to Connect to Microsoft Exchange using HTTP. Click on the Exchange Proxy Settings button:

Enter the external web address of the Exchange server (ie the address used for Outlook Web Access) in the fields as shown above. In the second text field, the ‘msstd’ is required!

Click OK, OK again, Next and then Finish.

Now launch Microsoft Outlook.

You will be prompted to enter your NT domain login credentials:

Enter your username in the form ‘DOMAIN\Username’

You will now be connected to the Exchange server:

Exchange 2007 Features

Architecture

It has always been possible to run Exchange on a single server, indeed the Small Business Server product is designed as a complete one-box solution for small and medium-sized businesses. However the ability to deploy different server roles onto different boxes offers increased security, scalability and flexibility.

It was Exchange 2000 that first offered the concept of front-end servers: an optional method of deploying an Exchange server to ‘load-balance’ incoming client requests to the correct back-end mailbox server, as well as requiring that users need only remember one server address when accessing their email via Outlook Web Access (OWA) or Exchange ActiveSync (EAS), regardless of where their mailbox be physically located.

Exchange 2007 has expanded on this approach, allowing the administrator to allocate specific Exchange-based roles to specific servers and deploy a ‘distributed’ messaging infrastructure.

An Exchange 2007 deployment can be separated into the following roles:

• Client Access – similar to a front-end server in an Exchange 2000 or 2003 installation. This server receives incoming client requests and directs them to the correct back-end mailbox server. This server runs Outlook Web Access, Server ActiveSync, POP & IMAP (if enabled) as well as receiving RPC over HTTP(s) requests.
• Mailbox – stores user mailboxes and public folders.
• Hub Transport – routes all messages, be they between users on the same mailbox server, from Unified Messaging servers, or external messages from Edge servers. Also enforces the messaging policy for messages moving within and outside the company (size limits, number of recipients allowed, etc).
• Unified Messaging – enables PBX integration to allow voice mail and fax messages to be delivered to the user’s Exchange mailbox. Also provides ‘voice dial-in’ feature enabling users to dial into their mailbox to have voicemails played back or emails ‘read’ to them. This feature is known as Outlook Voice Access which I will look at in more detail.
• Edge Transport – can reside outside the company network and provides routing, anti-spam and anti-virus services.

The Edge Transport server can be placed in a DMZ environment with no requirement for any inbound TCP ports to be open to the internal network. The Hub Transport server establishes an outbound-initiated connection with the Edge Transport server using a protocol designed for purpose called EdgeSync.

The EdgeSync protocol also sends information to the Edge Transport server on existing mailboxes and addresses as well as safe-sender lists to reduce the number of requests to the internal network to verify the validity of spam messages.

The Client Access Server should not be placed in the DMZ, despite being Internet-facing, due to the fact that it needs to be able to issue RPC requests to the Active Directory.

Exchange 2007 supports an unlimited information store database size. Standard edition supports up to 5 storage groups and databases per server, Enterprise Edition up to 50.

Possibly the biggest difference with Exchange 2007 is that it can only be installed on 64-bit hardware and the 64-bit version of the Server 2003 operating system (Server 2008 also only being available in 64-bit). In real terms this means that the operating system can address up to 16 Exabytes of memory (264), as opposed to the 4GB supported by 32-bit systems.

New Features

Increased security – with Exchange 2007, all messages sent between servers within the same organisation are encrypted using TLS (Transport Layer Security). All client communications, be they via OWA, ActiveSync or RPC over HTTP are all encrypted using SSL.

All Exchange 2007 servers are configured with a self-signed SSL certificate automatically.

Exchange Management Console – the Exchange Management Console has been reorganised to reflect the role-based architecture of Exchange 2007. With Exchange 2007, Exchange Administrative Groups have been done away with. Permissions are now delegated at the organisation level. Administrative groups allowed for permissions to be assigned to specific groups, but once created were quite limiting: a server could not be moved between administrative groups, for example. Routing Groups have also been done away with, Exchange 2007 instead using the existing Active Directory Sites and Site Links topology to route email between Exchange servers within the same organisation.

• Organisation Configuration allows you to configured Exchange global data that applies to all servers running a particular server role.
• Server Configuration allows you to manage the servers based on their roles. You can use this area to configure all of the Exchange servers and their child objects.
• Recipient Configuration allows you to manage the Exchange recipients.
• The Toolbox provides a central location for Exchange administrative tools and troubleshooters.

Exchange Management Shell – the Management Shell is a command-line scripting technology that allows the administrator to perform complicated actions against a number of sources, including the mailbox database and Active Directory, with minimal code and avoiding the need to ‘point and click’ within the Management Console.

Outlook AutoDiscover – this feature removes the need for users to know the name of their Exchange server when creating an Exchange profile within Outlook. All the user needs to know is their username, password and email address.

When the user enters their email address, the Outlook client performs an MX lookup via DNS to locate the Exchange server for the domain. A configuration request is then issued to the Exchange server, which is accepted by the Client Access Server. The appropriate configuration information is then returned to the client automatically. This requires a DNS entry for 'autodiscover.domain.com'

Improved Outlook Web Access – Exchange 2007 OWA has been updated to have a general look and feel more like Outlook 2007, to ‘streamline the user experience’ as marketing types might say. One immediately apparent difference is the log in screen, whih gives the users the option of specifying whether they are connecting from a ‘public’ (ie untrusted) or ‘private’ (ie trusted) computer:

There is also the option of selecting ‘Outlook Web Access Light’ which only displays a reduced amount of features. Microsoft say this mode is useful for those accessing OWA over a slow Internet connection. Actually ‘light’ mode looks in IE how ‘full’ mode looks in all browsers other than IE. Indeed OWA 2007 in Firefox doesn’t give you access to any of the more advanced features that are available in Internet Explorer.

OWA Share Access – Exchange 2007 Outlook Web Access provides users with the ability to access Sharepoint or file shares enabling centralised access to information remotely, without the need for a VPN connection.

Within the properties of the OWA web site within the Exchange Management Console, the administrator can allow or disallow both File Share and Sharepoint access:

Different access rights can be granted depending on whether the user is connecting in from a ‘private’ computer or a ‘public’ computer (which users specify when they log in).

The administrator can then explicitly allow or disallow file shares on specific servers. The domain suffix can also be entered so that users need only enter the name of the server rather than its FQDN.

Within OWA, there is an entry for Documents along with the usual Mail, Contacts, Calendar, Tasks, etc:

Selecting the option to Open Location allows the user to enter the name of a file share (for example, ‘\\UKFILE01\’). Provided that the administrator has allowed access to this share, the contents of the directory is listed in the IE window, with the option of ‘view in Windows Explorer’, in exactly the same way that FTP sites are handled by IE.

OWA Document Viewing – Outlook Web Access 2007 also has the ability to convert a variety of document types into HTML so that that document can be viewed on the client in a browser window, even if the application that was used to create the document is not installed on the client. Formats include Word, Excel, Powerpoint and PDF files.

Flexible Out of Office Rules – this feature allows the user to configure different Out of Office rules for internal and external users. Each rule can be given a start and an end date.

Unified Messaging – this feature gives users central remote access to all forms of business communications, including email, voice mail and fax messages, in one location – their Exchange Inbox. Voicemail, faxes and emails are delivered to the Inbox where they can be accessed from a range of clients – OWA, EAS, Outlook, etc. With the new Outlook Voice Access technology, users can dial into the UM Server from any ordinary telephone and access their Email, Voicemail, Contacts and Calendar. Once dialled in, users can manage their Inbox over the phone by saying commands such as 'delete message' or 'forward message', etc. I admit I have played with this feature briefly and was impressed, but did find that if there is any background noise the auto attendant got confused and there was a lot of "I'm sorry I don't understand that command" so I expect it's brilliant if you're in the car with all the windows shut and the radio off, but not so good if you're on a crowded platform.

The UM functionality requires that the Exchange Server be linked into the corporate telephone system. If an IP PBX is used, then the PBX can communicate with the UM Server directly using the SIP VoIP protocol (Session Initiation Protocol). If a legacy PBX is used, then a VoIP gateway will need to be deployed between the PBX and the UM server.

If a user’s telephone extension is not available, voicemail messages can be recorded and notification sent to the user's Inbox. That user can then dial in to listen to the message, or choose to download it as a sound file.

The UM server can also be integrated into the corporate PBX to provide an auto attendant that can transfer you to the person you wish to speak to based on the information held in the Global Address List, using Speech Recognition technology.

The diagram below gives an overview of the functionality using Outlook Voice Access, or OVA:

This image is available in PDF format from the Microsoft web site, here:

http://download.microsoft.com/download/6/7/e/67ef31de-9ee0-47aa-a2ff-a89...

Users have the ability to edit some of the OVA features within OWA, as well as resetting their PIN number should they forget it:

Exchange ActiveSync – Users can now manage their mobile devices through Outlook Web Access. For example, if a device is lost or stolen, the user can remotely ‘wipe’ or ‘kill’ that device through OWA without needing to speak to their corporate IT department.

Administrators can now also define separate per-user or per-group ActiveSync policies with different settings, for example allowing or disallowing attachments.

Windows Mobile 6.1 devices provide users with the ability to manage their Out of Office status and messages directly from their device.

Exchange 2007 also provides the administrator with the ability to remotely manage their device fleet by deploying corporate policies defining how those devices can be used, including the ability to disable hardware and software elements on the device as well as blacklist applications.

File shares can also be accessed from Windows Mobile 6.1 devices without the need for a VPN connection. In the same way that file shares can be accessed via OWA. The shares available can be defined independently from OWA:

Summary

In short, then, Exchange 2007 has been developed with mobility very much the focus. The requirement for 64-bit architecture will require the purchase of new hardware for most companies and if you plan to make the most use out of a separate EdgeSync server then this will add to the cost. The question you have to ask is do the benefits outweigh the expense?

Exchange 2010 Features

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:

• Download and install a trial copy of Windows Server 2008 R2 64-bit, available from the Microsoft web site - http://www.microsoft.com/windowsserver2008/en/us/trial-software.aspx
  NOTE - Exchange 2010 will only install on Windows Server 2008 64-bit
• Assign the server name and a fixed local IP address, set the primary DNS server to the localhost address
• Install the Active Directory Domain Services role. Once complete, run DCPromo.exe and create a new domain controller in a new forest
• Add the Web Server role using the default options
• Add the Application Server role using the default options. A reboot will be required at this point
• Install the Microsoft Office 2007 Filter Pack (http://go.microsoft.com/fwlink/?linkid=123380), required for web document viewing in OWA
• Install the Windows Desktop Experience (listed under "Server Features"), required for the Exchange Unified Messaging role (as it includes the Windows Media Audio Codec). A reboot will be required.
• Add the Certificate Services role using the default options
• Set the startup type for the "Net.TCP Port Sharing Service" to Automatic

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:

• Password enforcement
• Synchronisation size limits
• Hardware control
• Software control
• Remote file share access

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!

• Display email messages in conversation view
• Define synchronisation rules for whole 'conversations' (ie do not sync, delete, move to folder, etc)
• Synchronise SMS text message folders with your Exchange mailbox (and thence to Microsoft Outlook and OWA)
• Support for Message Reply status - if you reply to an email within Outlook or via OWA rather than on your Windows Mobile device, this will still be reflected on the Windows Mobile device and indicated by the message icon
• Support for Free/Busy status, enabling you to view at a glance whether a contact is in a meeting or on holiday or not

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:

Exchange 2010 Service Pack 1 (Beta)

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.

Outlook Web Access

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.

Exchange ActiveSync

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

Restricting access to Exchange 2010 ActiveSync

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:

• Email and PIM data
• Free / Busy lookup
• Unified Messaging access
• Remote file share / Sharepoint access
• SMS message synchronisation

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:

• Enforce password usage and strength
• Password entry attempts
• Synchronisation size limits
• Disable removable storage
• Disable camera
• Disable WiFi
• Disable Infrared
  Disable remote desktop from device
• Disable desktop synchronisation
• Disable Bluetooth
• Disable Browser
• Disable POP/IMAP email
• Disable application installation
• Whitelist and blacklist applications

(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:

• Device Model
• Device Type
• Device OS
• Device User Agent

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:

• Device IS - BC2DD3AE37CE0CB225D6D0BDBFECCC69
• Device Model
• Device Type - PocketPC
• Device OS
• Device User Agent - MSFT-PPC/5.2.1403

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:

• Hourly
• PolicyCompliance
• Servers
• StatusCodes
• UserAgents
• Users

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.

Synchronising SMS Messages between Windows Mobile 6.5 and Exchange 2010

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:

Installing Microsoft Office Communications Server 2007

This is slightly off-topic, but I wanted to install OCS 2007 Server, not having done it before, in order to be able to then test connectivity from other devices including BlackBerry, and Android if/when a client is made available. Normally I wouldn't blog about the installation of a relatively common Microsoft server product, but I ran into a number of errors so thought I'd detail how they were resolved in case anyone else runs into the same problems.

The procedure I ran through was as follows:

• Install Windows Server 2003 SP2.
• Add the server to the domain.
• Install IIS, including the ASP and Message Queuing services.
• Install Certificate Services (only required if a CA is not already present on the domain elsewhere).
• IMPORTANT (this is where I ran into problems) - if Microsoft hotfix package 974571 is installed, uninstall it before beginning the installation of OCS. Failure to remove this hotfix will prevent you from being able to activate the OCS server one the program files have been installed.
• Create a DNS entry for the OCS server (or pool if required).

Raise the Domain Functional level from Mixed Mode to Server 2003 Native Mode

On the domain controller, open the Active Directory Domains and Trusts MMC snap in. Right click on the Domain and select the option to Raise Domain Functional Level. If the domain is set to Mixed Mode, it will need to be raised to Server 2003 Native Mode.

Click OK and then run a gpupdate /force command to force the change to replicate through the domain.

Create required service accounts

Create a new domain User Group called 'RTCSetupDelegate'.
Create two new domain user accounts: 'RTCService' and 'RTCComponentService' and add them both to the RTCSetupDelegate group created earlier.

Launch the OCS Installer

Log into the OCS server with a domain user account with both local admin rights on the OCS server and SchemaAdmin rights on the domain.

Launch the OCS installer application, if prompted to install the Visual C++ redistributable, select Yes.
Run the Forest Prep wizard followed by the Domain Prep wizards and ensure they complete successfully. Once completed, run another gpupdate /force command on the domain controller to force a replication throughout the domain.

Delegate setup tasks to required service accounts

Delegate the setup and administration tasks to the two RTCService user accounts created earlier. Launch the Command Prompt and navigate to the directory containing the OCS installer files. Browse to the \setup\i386 directory.

Run the following commands:

(Read the following Microsoft Technical article for full information - http://technet.microsoft.com/en-us/library/bb905930.aspx)

To delegate Setup:

LCSCmd.exe /Domain:domain.com /Action:CreateDelegation /Delegation:SetupAdmin 
/TrusteeGroup:RTCSetupDelegate /TrusteeDomain:domain.com /ServiceAccount:RTCService 
/ComponentServiceAccount:RTCComponentService /ComputerOU:DC=domain,DC=com

To delegate Server Admin:

LCSCmd.exe /Domain:domain.com /Action:CreateDelegation /Delegation:ServerAdmin 
/TrusteeGroup:RTCSetupDelegate /TrusteeDomain:domain.com /ServiceAccount:RTCService 
/ComponentServiceAccount:RTCComponentService /ComputerOU:DC=domain,DC=com

To delegate User Admin:

LCSCmd.exe /Domain:domain.com /Action:CreateDelegation /Delegation:UserAdmin 
/TrusteeGroup:RTCSetupDelegate /TrusteeDomain:domain.com /ServiceAccount:RTCService 
/ComponentServiceAccount:RTCComponentService /ComputerOU:DC=domain,DC=com 
/UserOU:CN=Users,DC=domain,DC=com /UserType:User

To delegate Read Only Server Admin:

LCSCmd.exe /Domain:domain.com /Action:CreateDelegation /Delegation:ReadOnlyAdmin 
/TrusteeGroup:RTCSetupDelegate /TrusteeDomain:domain.com /ServiceAccount:RTCService 
/ComponentServiceAccount:RTCComponentService /ComputerOU:DC=domain,DC=com

To delegate Read Only User Admin:

LCSCmd.exe /Domain:domain.com /Action:CreateDelegation /Delegation:ReadOnlyAdmin 
/TrusteeGroup:RTCSetupDelegate /TrusteeDomain:domain.com /ServiceAccount:RTCService 
/ComponentServiceAccount:RTCComponentService /ComputerOU:DC=domain,DC=com 
/UserOU:CN=Users,DC=domain,DC=com /UserType:User

Run the Deploy Server wizard to install the required program files to the server. At the end of the installation, the wizard will then attempt to activate the OCS server. If the wizard fails with an error along the lines of 'the server clock may not be set correctly', again verify that hotfix 974571 is NOT installed on the server. If it is, uninstall the hotfix, then attempt to activate the server manually at the command line with the following command:

LCSCmd.exe /Server:ocs.domain.com /Role:SE /Action:Activate /Password:PaSSword1

(where PaSSword1 is the password of the user account used to install the OCS software - the account currently logged in, not the RTCService account)

Return to the OCS installer wizard and resume where you left off.

Issue a certificate request to the online CA and assign it to the OCS server. Start all OCS services.
Under the "Deploy Other Roles" section, select the option to deploy the Communicator Web Access server role, assigning the certificate generated earlier when prompted.

If all has gone well, you should see the server roles listed within the Office Communicator Server MMC snap-in within Administrative tools, and several new context menu items within Active Directory:

The Communicator Web Access (CWA) web site should be listed in the CWA MMC snap in:

And browsing to https://(server)/cwa should display the Communicator Web Access login screen:

In my next post I shall detail how to set up the BlackBerry Enterprise Server solution to enable access to OCS from BlackBerry handheld devices.

Microsoft Server 2008 Terminal Services

I have blogged about the terminal services capabilities of Microsoft Server 2008 on previous, now defunct, blog sites and as it came up in a support call today I thought it was worth resurrecting my old article.

Terminal Services is a component of Microsoft Windows and Windows Server. If you have used Remote Desktop to remote control another Windows-based computer, then you have used terminal services already. It is so-called after the days when computing power used to be consigned to a central mainframe, and remote thin-client “terminals” would be used to access the processing power and applications held on that mainframe.
Simply put, Terminal Services allows users to access centrally-located application resources: suppose a user needs to edit a document written using Word 2007, but doesn’t have Word 2007 on his or her PC, and can’t justify the expense of a license for Office 2007 as they may only need to edit an Office 2007 document once in a blue moon – they can access a legitimately-licensed copy of Office 2007 installed on a terminal services server for the length of time they need to do their work, and then when they have finished, this application is then free for someone else to use, without having to install and then uninstall the software from their PC to maintain licensing adherence: the application has been “virtualised”.
At this point I should mention that this is probably not a good example: there are converters available for Word 2007 which can be used with previous versions of Office. Quark, perhaps, would have been a better example, but I’d already taken lots of screenshots of running Word 2007 in a remote terminal session before I started writing this post!

Windows Server 2008 has extended upon the terminal services capabilities of previous versions of the operating system.
Server 2008 Terminal Services Remote Application requires that the client machine be running Remote Desktop version 6.1 – in real terms this means Windows XP Service Pack 3, or Windows Vista Service Pack 1. This can be installed via Windows Update if not already installed.
The principal difference between this release and previous implementations, is that with Server 2003 and prior, applications were run in a remote desktop session, whereas with Server 2008 applications are still running “remotely”, but appear to run on the local machine desktop as if they were installed locally: the same remote desktop protocol is used, but the single application loads and is displayed in single application window, alongside other running applications, rather than the entire desktop of the remote machine. The remote application has its own entry in the taskbar along with local applications, and the window can be maximised and minimised as well as resized, as with local applications. The remote application can also use the “notification area” on the local PC (the system tray). Local drives and printers can also be directed to the remote application.
As far as the user is concerned, they have no means of knowing, necessarily, that the application isn’t running on the local machine, virtualisation technology hiding the physical characteristics of the application from the end user.

Applications can be accessed in two ways:

• Terminal Services Remote Application (TS RemoteApp)
• Terminal Services Web Access (TS Gateway)

RemoteApp programs can be launched in a number of ways: an RDP file can be launched from the client PC, which contains details of the program’s location, as well as security parameters concerning what the application can access on the local machine, or alternatively the remote application can be installed on the PC from an MSI file, which adds the program to the Start Menu and associates the correct file extensions for use with the application.

Terminal Services Web Access enables users to launch applications by selecting them from a web site.

Benefits

Besides the benefit of ease of license administration, there are other clear benefits: client devices can be used simply as thin-clients: no data need be stored on the local machine, meaning that should a laptop be lost or stolen there is no sensitive information held on it.
There is no need to keep multiple copies of the same application installed on multiple workstations, kept up to date and patched: only a single copy of the application needs to be maintained.
Because the application is running on central hardware that is more than capable of running that application, the client hardware does not necessarily need to be able to run the application natively. Therefore PCs that could never hope to run Office 2007 locally can access it – provided that they support the Remote Desktop Protocol (RDP).
As opposed to Remote Desktop, which transmits the entire desktop to the remote user, and can quickly generate a large amount of data to be transferred; application virtualisation only requires that key-presses and mouse movements be transmitted over the network (and the remote session can be encrypted using TLS encryption is desired). This means that relatively “complicated” applications can still be accessed even over low-bandwidth connections. Also, because the data that is sent between client and server can be encrypted, applications can be accessed remotely even when out of the office, without the need for a separate VPN infrastructure.
This remote access technology can also be combined with Server 2008 Network Access Protection (NAP) technology to ensure that remote clients can only access the application server if they have current anti-virus definitions and meet 'baseline' security requirements defined by the administrator.

Configuring the server

The Terminal Services role is added to the server via the Server Manager application. If you wish to use the Web Access component, then the Web Server (IIS) role should be added also. Once installed, the TS RemoteApp Manager will be listed within the Server Manager:

Applications installed on the server can be “enabled” for RemoteApp use selecting the Action to Add RemoteApp Programs. The Add RemoteApp Program wizard will be displayed:

Click Next. A list of available applications will be displayed:

Select the application(s) you wish to enable and click Next

Click Finish. The wizard is now complete and the applications are enabled. Available applications are listed in the RemoteApp Programs window pane:

Right clicking on a program allows the administrator to create an RDP or MSI configuration file for the application which can be deployed to the client machines. Applications can also be hidden or added to the Web Access view from here:

Selecting the option to create an RDP file will launch the RemoteApp Wizard:

Click Next. Specify the location where you wish the RDP file to be saved, and also configure certificate and Terminal Server Gateway settings:

A Terminal Server Gateway can be deployed in a DMZ environment which accepts RemoteApp from client machines and relays them through a corporate firewall to the Terminal Server on the local network. Click Next:

The wizard is now complete, click Finish.

Selecting the option to create a Windows Installer Package will launch the same wizard:

Click Next. Specify where you want the resulting MSI file to be saved and configure certificate and TS Gateway settings:

Click Next. Specify where on the client machine you want the resulting shortcut to be installed:

Click Next and then Finish.

Configuring the client

Once the RDP or MSI file has been created on the server, it will need to be copied to the client machine.
Running the MSI file will create a shortcut on the client machine in the location specified when the MSI file was created:

RDP files can be double clicked to initiate them. When launched, a connection to the Terminal Server will be established and the user will be prompted to enter a username and password to access the program:

Once authenticated, the user can then specify what resources on the local machine they wish the remote application to have access to:

The application will then load:

(the above screenshot shows that Office is not installed locally on the machine).

Web Access

By default, web access to the Terminal Server is located at http://(servername)/ts (https would be required if certificate-based access had been configured). The web interface will display a list of programs that have been enabled for web access:

Clicking an icon will launch the connection to the RemoteApp. The user will be prompted to specify what local resources the remote application should have access to:

The user will then be prompted to enter a username and password to authenticate the connection:

The application will then launch. The fact that the application is remote will be indicated by the presence of “(Remote”) in the name of the application window.

From an administrative point of view, web access is the simplest means of deploying applications: the client does not need an RDP or MSI file to be sent to it, the user simply needs the address of the web site.

Searching public folders with Outlook 2007

Unlike previous versions of Outlook, Outlook 2007 uses (and therefore requires that it be installed), the Windows Desktop Search software.

In order for this to be able to search public folder content, these folders must be stored locally in Cached mode. Public folder caching is not enabled by default, and must be enabled in the Advanced properties of the Exchange Account:

Rather than sync the entire public folder directory, only “Favourite” folders are synced, therefore target public folders must be added to the Favourites before they will be cached and then indexed. To add a favourite, right click on the folder entry and select “Add to Favourites”:

Search results will now include the public folder favourites.