Exchange 2003 Mobile Messaging

[patris1]

http://www.msexchange.org/tutorials/Exchange-2003-Mobile-Messaging-Part1-Microsoft-DirectPush-technology.html

Henrik Walther

Part 1 - A look at the Microsoft DirectPush technology


Introduction

Prior to Exchange 2003 SP2, you had two choices for synchronizing a mobile device with a mailbox; you could manually configure ActiveSync on the mobile device to issue synchronization on a scheduled basis, or you could make use of the Always-up-to-date (AUTD) technology. The problem with scheduled synchronizations is that you cannot schedule them for intervals less than five minutes, which means you will not always have the latest information on your device. Another problem is that you (depending on your mobile operator) will be charged for each established session, as new data will travel over the wire, each time a new session is established.

AUTD makes it possible to keep your device up to date by generating an Exchange store event in the user’s mailbox. When the store event detects a change in the mailbox, it triggers a Short Message Service (SMS) control message, which is then sent to the user’s mobile device. When the device receives the SMS message it initiates synchronization with the Exchange server. The idea behind the AUTD technology is good, but unfortunately it doesn’t work very well in reality, at least not in Europe where very few mobile operators supports AUTD. Microsoft IT became aware of this problem, when they deployed Exchange 2003 based mobile messaging in their own organization – an organization spread all over the world.
Based on customer feedback regarding the limitations of using SMS to notify a supported device, Microsoft improved the AUTD experience in Exchange Server SP2 based on the following goals:

• A standard data plan is the only subscription you need to synchronize with Exchange (which must work globally)
• No need to deploy additional infrastructure in your Exchange environment
• No need for SMS notification or any other “out-of-band” schemes
• No special configuration on the device

And this is basically what the Exchange DirectPush technology delivers. Microsoft has been testing this new technology on their own servers for a while, and with great results. The DirectPush technology keeps your mobile device up-to-date by delivering e-mail, Calendar, Contacts and Tasks directly to your device, allowing you to react quickly to changes in your mailbox. AUTD v1 did the same thing but DirectPush offers several benefits.

Note:
When enabling DirectPush on the Exchange 2003 Server, devices that are currently configured to use AUTD v1 are automatically switched/migrated from AUTD v1 to DirectPush. This means you don’t need to reconfigure anything on the device after enabling the feature.

The cool thing about the DirectPush technology is that it maintains an HTTPS connection between the Exchange server and the mobile device, a session which is kept alive by using heartbeats. This way the Exchange server can notify a mobile device whether or not there’s a change in the associated mailbox, and if a change occurs in the mailbox, the server can initiate a synchronization. Since the device keeps an open session to the Exchange server, some of you might think this could become rather expensive. But fear not because the device simply sits there and waits for a response, it doesn’t send or receive any data when it’s in this pending state.Said in another way, no data will travel over the wire, unless a change is detected in the mailbox, or the heartbeat expires.To get a more visualized picture of how the DirectPush technology works, see Figure 1 below.

Figure 1: Overview of the DirectPush Technology

Because the mobile device doesn’t send any empty syncs, as is the case with scheduled or manual syncs, the device reduces its power consumption which again increases battery life. Additionally data charges are reduced significantly. It’s also worth noting that any data synchronized between the mailbox and the devices are compressed using GZIP compression.


DirectPush requirements

Server-side
As the DirectPush feature is a new technology included in Exchange 2003 SP2, it’s required that you apply Exchange 2003 SP2 at least on the Exchange 2003 front-end servers in your organization. Note that I say front-end servers, because your back-end servers can run anything from Exchange 2003 RTM, SP1 to SP2 as long as you have one or more front-end servers with SP2 applied. But although DirectPush doesn’t require it, I still recommended you upgrade the back-end servers to SP2 as well, not because you will gain any advantage out of doing so when it comes to the DirectPush technology, but because the service pack is packed with new great features and improvements as well as a lot of bug fixes. You can read more about the stuff included in Exchange 2003 SP2 in a previous article of mine.

Note:
In addition to the above requirements it’s highly recommended you adjust the time-out values for HTTPS connection in your firewall (more on this later in the article).

In order to properly secure Exchange ActiveSync, it's best practice, as well as my personal recommendation, to publish the service using an ISA Server 2004 firewall, see Figure 2 below for a general best practice scenario.

Figure 2: Microsoft DirectPush Topology

Client-side
Another requirement in order to make use of the DirectPush technology is that the mobile devices need to run Windows Mobile 5.0. In addition the devices need to have the Messaging and Security Feature Pack (MSFP) installed. Although Microsoft shipped firmware that included the MSFP to mobile device manufactures back in October 2005, new firmware releases with the MSFP included have been heavily delayed. But March 2006 seemed to be the month where things started to kick off. Both i-mate and Qtek as well as Orange have finally released new firmware updates with the MSFP included, although so far only for their newer models.

Note:
The Messaging and Security Feature Pack (MSFP) is also known as the Adaption Kit Update 2 (AKU2).

Enabling DirectPush on the Exchange 2003 Server(s)

When Exchange 2003 SP2 has been applied, the DirectPush feature will be enabled by default. The feature can be found in the same place as the other Exchange mobility features are located, which is on the property page of the Mobile Services object in the Exchange System Manager (see Figure 3 below).

Figure 3: Enabling DirectPush in the Exchange System Manager

Note that even though the DirectPush feature has been enabled, mobile devices without the MSFP installed are still capable of doing synchronizations using either the manual and/or scheduled methods, or via AUTD.
Exchange 2003 Server heartbeat time-out values

In order to maintain a persistent connection between an Exchange server and a mobile device, DirectPush makes use of so called heartbeat intervals. This is so that the server can keep a connection open to a device all the time, even though no changes occur in a mailbox. The Exchange server adjusts this heartbeat interval automatically, it keeps the last heartbeat interval received from a device. But you can also configure the value for the heartbeat intervals in a set of registry keys on the Exchange server, although it shouldn’t be nescessary. For details on how you configure these values, I recommend you take a look at MS KB article 905013.
Firewall considerations

In order to maximize performance as well as provide a better always-up-to-date experience for the end-users, it’s highly recommended that you increase the time-out values for HTTPS connections on your firewall. Depending on what type of firewall is used in your organization, this is of course done differently. For steps on how to do so on an ISA Server 2004 firewall see MS KB article 905013, these steps should give you an idea of how you should approach this with another firewall product as well.

Note:
Failing to set the time-out on the firewall to minimum 15 minutes (MS recommends 30 minutes) will among other things result in poor battery life time on the mobile devices as well as increase data transfers over the wire.

Enabling DirectPush on the mobile device

It’s time to see what is required on the mobile device in order to get it to synchronize with the Exchange server using DirectPush. Let me be honest and tell you there’s nothing new when it comes to configuring ActiveSync on the device, actually you only need to enable Microsoft DirectPush under the Comm Manager as shown in Figure 4 below, and the device will issue an HTTP (ping) request to the Exchange server and we’re pretty much there.

Figure 4: DirectPush on a mobile device with the MSFP installed

When DirectPush has been activated on the device, an icon consisting of two small vertical arrows appears in the top right corner of the screen (see Figure 5). When a change is detected in the mailbox, or if the heartbeat expires, the server will issue a response back to the device, which will then do a synchronization of the respective mailbox, or re-issue an HTTP request.

Figure 5: DirectPush enabled on the mobile device

DirectPush Performance Counters

When you install Exchange 2003 SP2 on an Exchange Server, several DirectPush related performance counters are added to the server as well. These counters can be found under the Microsoft Exchange ActiveSync performance object, as can be seen in Figure 6 below.

Figure 6: DirectPush related performance counters

Notice all the counters measuring so called Ping commands. Ping (which shouldn’t be confused with a traditional Ping command) is the command or request that’s sent by the mobile device to the server via an HTTP(S) connection. This request will then be in a pending state until a change occurs in a mailbox, or until the heartbeat interval expires.

As with any other performance counter you can get a description of each DirectPush related counter by marking it, then click the Explain button (see Figure 6).
Conclusion

The new DirectPush technology provides a much richer experience for your end-users, and even though DirectPush isn’t real push technology (like is the case with RIM’s Blackberry product), the end-user will never notice as it is a matter of seconds before a change occurring in a mailbox (e-mail, calendar, contacts and tasks) is synchronized to a mobile device. Due to the fact that the DirectPush technology is an integrated part of Exchange 2003 Servers with SP2 applied, the investments required can be kept at a minimum, as the only thing you need to invest in is mobile devices running Windows Mobile 5.0 and have the MSFP installed

---

موضوعات مشابه:

• How to connect mobile employees and Exchange 2003 using Windows Small Business Server 2003 R2
• SolutionBase: Administering mobile messaging in Exchange Server 2007
• Fax in Exchange 2007 Unified Messaging
• Mobile Messaging with Exchange Server 2007

---

[patris1]

http://www.msexchange.org/tutorials/Exchange-2003-Mobile-Messaging-Part2-Uncovering-Device-Security-Policies.html

Part 2 - Uncovering the Device Security Policies


Introduction

We all know how easy it is to lose a mobile device, or even worse have it stolen. Now that we have the possibility of synchronizing our devices with a mailbox, we need a way to properly secure our devices, so that any corporate information or other sensitive data can be held secure. With Exchange 2003 SP2 applied, you as an administrator have the possibility of configuring mandatory PIN or password requirements for the Windows 5.0 Mobile Devices that synchronize with the Exchange servers in your organization. You could for example configure a device to require a four-digit personal identification number (PIN), that the users would need to enter before they were allowed access to their device. If a user were to enter this PIN incorrectly let's say four times, you could even configure the device security settings so that all data on the device would be erased (equal to a local wipe).

Note:
If you haven't already seen it, I highly recommend you checkout this video before you continue reading this article, it demonstrates how device security policies, as well as the remote wipe functionality, works in practice.

Configuring the Device Security Policies

The device security policies are configured within the same place as the other mobile device related settings, and that is under the Property page of the Mobile Services object in the Exchange System Manager (see Figure 1).

Figure 1: Property page of Mobile Services in the Exchange System Manager

When you click the Device Security button you get to the page where you configure the different Device Security Settings (see Figure 2).

Figure 2: Device Security Settings

As the device security settings are global (yes that's correct they're applied to every single user connecting to the Exchange Servers in your organization), it's rather important you know the exact purpose of each setting. I've therefore listed all of them with a description in the table below.

Device Security Setting
Description
Enforce password on device
Activates the device password policy. None of the device security settings will work before the feature has been enabled.
Minimum password length (characters)
Enable this option to specify the required length of the user's device password. The default setting is 4 characters. You can specify a password length of 4 to 18 characters.
Require both numbers and letters
Enable this option if you want to require that users choose a password with both numbers and letters. This option is not selected by default.
Inactivity time (minutes)
Enable this option to specify if you want your users to log on to their devices after a specified number of minutes of inactivity. This option is not selected by default. If selected, the default setting is 5 minutes.
Wipe device after failed (attempts)
Enable this option to specify if you want the device memory wiped after multiple failed logon attempts. This option is not selected by default. If selected, the default setting is 8 attempts.
Refresh settings on the device (hours)
Enable this option to specify how often you want to send a provision request to devices. This option is not selected by default. If selected, the default setting is every 24 hours.
Allow access to devices that do not fully support password settings
Select this option if you want to allow devices that do not fully support the device security settings to be able to synchronize with Exchange Server. This option is not selected by default. If this option is not selected, devices that do not fully support device security settings (for example, devices that do not support provisioning) will receive a 403 error message when they attempt to synchronize with Exchange Server.
Table 1: Description of the Device Security Setting

In addition to the settings in the table, there's also an Exceptions button (see Figure 3.) After clicking this button you can specify the users who you want to be exempt from the settings that you have configured in the Device Security Settings dialog box. This exceptions list can be useful if you have specific trusted users (or perhaps managers!) of whom you do not need to require device security settings.

Figure 3: Device Security Exception List

Be sure you don't configure a device security policy that is too strict, as this could end up with frustrated users erasing their devices all the time. Also remember a user in some situations could have problems contacting the IT department if his device has just been erased. Users are already used to four-digit numbers (among other things from their credit cards) so requiring a four-digit number would in most situations be a good idea. Actually the best solution would be to use a four-digit number in combination with a reasonably configured wipe device after failed attempts setting to make sure you don't become unpopular.
Storage Location of the Device Security Settings

So where are all the device security settings stored? Almost all the values configured under the device security settings page are stored in Active Directory, more specifically in an attribute called msExchOmaExtendedProperties, which can be found under CN=Outlook Mobile Access,CN=Global Settings,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC =com using a tool such as ADSI Edit (see Figure 4).

Figure 4: Location of Security Device Settings in Active Directory

If you select the msExchOmaExtendedProperties attribute and click the Edit button you get to the screen shown in Figure 5 below.

Figure 5: msExchOmaExtendedProperties attribute

As you can see, all the device security related values are stored in a string prefixed PolicyData. The values are encoded between the <wap-provisioningdoc> tags. Because this is nothing else than a XML blob, you have the possibility of provisioning your own custom policies by specifying the required values in an XML format similar to this one. It would have been nice to be able to set these policies per user via the GUI but for now the only way to configure these settings on a per user basis is to configure the msExchOmaExtendedProperties attribute on each user, but that's not exactly a friendly method is it? Good thing is I've heard Microsoft will make it possible to configure these settings per user, using GPOs or a similar approach; the bad thing is this won't be before Exchange 12 RTMs. Until then I can only recommend Dan Winter & Marc Nivens implement this possibility in their ADModify.net tool (you can read more about ADModify.net in a previous article of mine).
Because of the complexity of this subject, I won't go into further details on how you accomplish this, but instead suggest you checkout this blog entry over at the You Had Me At EHLO blog.
Mobile Devices

When you have configured and enabled the device security settings on the server, the dialog box shown in Figure 6 below will appear on the device during the next synchronization with the server.

Figure 6: Security policy enforced on device

After clicking OK you need to specify and confirm the PIN or password you want to use. The PIN or password needs to be entered every time the device is unlocked or after you have issued a cold reset. If an incorrect password is entered, perhaps because one of your kids was playing with the device or if you forgot to lock the keypad while the device was in your pocket, you'll get a message similar to the one below:

The password you typed is incorrect. Please try again. 1/5 attempts have been made.

This of course depends on how many allowed attempts you have specified under Wipe device after failed option in your Device Security Settings (refer back to Figure 2).
After the second failed attempt you'll be notified that several incorrect passwords have been entered. In order to confirm the login attempt is not due to accidental button presses, you're asked to enter A1B2C3 or something similar (depends on how the mobile provider configured this in the specific build). When you have entered these characters you'll once again have the option of specifying your device password. Should you for some reason manage to enter it incorrectly once again, you're faced with the incorrect password dialog box again. Before the last available attempt you'll be informed that all information on the device will be erased after the next unsuccessful password attempt. An erase (similar to a local wipe) will clear out all memory on the device, i.e. the device will be reset back to its factory defaults. Bear in mind though that data on the storage card in the device will remain intact. You can argue whether this is a good design decision or not, personally I think this is a major security risk factor, especially because you can configure the device to store e-mail message attachments on the storage card!

Note:
If you know for a fact that a device has been lost or stolen, you can also initiate a remote wipe to the device, a remote wipe wipes the device immediately. We'll talk more about this possibility in part 3 of this article series.

Changing your Device PIN or Password

If you want to change your PIN or password, you do so by clicking Start > Settings > Lock.

Figure 7: Lock button under the Settings page

You'll now need to enter your current PIN or password in order to access the change password feature, when you have done so, you'll get to the screen shown in Figure 8 below.

Figure 8: Changing your device password

It's also interesting to note that a locked device that is connected to a PC using a USB cable won't be accessible either, instead you'll be faced with the dialog box shown in Figure 9 below.

Figure 9: Connecting a locked device to a PC via USB

Conclusion

In this article you have learned how it's possible to make the mobile devices in your environment more secure by using the new security policy feature included in Exchange 2003 SP2. You have also seen how these device security settings work from the client side. The Device Security settings feature is a nice improvement when speaking about security, but it doesn't provide optimal security just yet. Among other things because data held on a storage card doesn't get wiped as part of a local or remote wipe. But hopefully we'll have a close to perfect solution with Exchange '12'.

In the next article I'll show you how to install the Exchange Server ActiveSync Web Administration tool, as well as how you can initiate remote wipes of lost or stolen devices with this tool and much more

[patris1]

http://www.msexchange.org/tutorials/Exchange-2003-Mobile-Messaging-Part3.html

Part 3 – Installing, Administering, and Using the Microsoft Exchange Server ActiveSync Web Administration tool


Introduction

In the last article in this series we covered how you, with the help of properly configured device security settings, could have a device erased (similar to a local wipe) after a user entered x number of incorrect PINs or passwords. But there may be situations where you want to have a lost or stolen device wiped immediately. This is where the Exchange Server ActiveSync Web Administration tool comes into the picture. The tool is designed for administrators who want to manage the process of remotely erasing lost, stolen, or otherwise compromised mobile devices.
With the Exchange Server ActiveSync Web Administration Web tool, administrators can perform the following actions:

• View a list of all devices that are being used by any enterprise user
• Select/De-select devices to be remotely erased
• View the status of pending remote erase requests for each device
• View a transaction log that indicates which administrators have issued remote erase commands, in addition to the devices those commands pertained to

The Microsoft Exchange Server ActiveSync Web Administration Tool is designed specifically for Exchange Server 2003 with SP2 applied and Windows mobile 5.0 devices, but the tool is also supported on SBS 2003. Bear in mind though that there are a few issues to be aware of when installing the tool on SBS 2003. I won’t go into detail on those issues here, but instead refer you to the Troubleshooting section in the Deploying Windows Mobile 5.0 with Windows SBS whitepaper.
Installing Exchange Server ActiveSync Web Administration tool

There’s no hocus pocus in installing the Microsoft Exchange Server ActiveSync Web Administration Tool, when you have downloaded a copy here you simply extract the MobileAdmin.exe file, then run the MobileAdmin.msi package on your Exchange 2003 SP2 front-end server (or back-end server if you only have one Exchange Server in your organization).

When the installation wizard appears click Next (see Figure 1 below).

Figure 1: Microsoft Exchange Server ActiveSync Web Administration Tool Installation Wizard

Accept the EULA then click Next once again. Let the installation complete, then click Finish to exit the installation wizard.
Using Exchange Server ActiveSync Web Administration tool

When the Exchange Server ActiveSync Web Administration tool has been installed, you can access the mobile admin tool from any remote computer by typing https://server/mobileadmin in your browser. You will then be asked to authenticate, and in order to access the tool you need to do so using an account which is a member of either Exchange administrators or local administrators on the server (or another group or account that has been given permissions to the MobileAdmin virtual directory, see instructions on how to do so later in this article).

When you have authenticated with an account with appropriate permissions, you get the Mobile Admin Web Form shown in Figure 2.

Figure 2: Mobile Admin Web Form

From here you can select between the two administrative options Remote Wipe and Transaction Log. Let’s start by selecting the Remote Wipe option. From here you can manage the user’s devices, or more specifically initiate remote wipes for specific devices and/or cleanup device partnerships (Figure 3).

Figure 3: Remote Device Wipe

In order to see which devices are associated with a particular mailbox, you need to either enter the mailbox name or SMTP address of the user. When you have done so you’ll get a list similar to the one in Figure 3, which has 5 columns, all listed below:

• Device Id
• Type (whether it’s a SmartPhone or PocketPC)
• Last Sync (time and data when last sync was performed)
• Status (Status of the device can be either OK, Wipe initiated, Sent to device, Device acknowledged and Wipe operation completed successfully)
• Action (where you can select to either Wipe a device or delete a partnership)

As you can see in Figure 3 one of the partnerships listed hasn’t been synchronized since November 2005, it should therefore be safe to delete it. So let’s hit Delete and see what happens. First we’re asked whether we really want to delete this partnership (Figure 4).

Figure 4: Partnership deletion confirmation box

When clicking OK the partnership is deleted and a few seconds later it will no longer appear on the list of associated partnerships. When a partnership is deleted it’s logged in the Transaction log as can be seen in Figure 5. Deleting a partnership will clean out all state information associated with the particular mobile device on the server, and is primarily useful for housekeeping purposes. If a device which had its partnership deleted is connected again, it will be forced to re-establish the deleted partnership with the serer through a recovery process. But don’t worry, this process is completely transparent to both you as the Exchange administrator as well as the end user.

Figure 5: Partnership deletion log entry in Transaction log

When you initiate a remote wipe action, it will remain active until you cancel it via the Cancel Wipe option shown in Figure 6, this means that the server will continue to send a remote wipe to a device (even though the device has been remotely wiped already), so remember to cancel the remote wipe action after a lost or stolen device has been recovered.

Figure 6: Remote Wipe initiated

As can be seen in Figure 7 below a remote wipe of a device will be logged in the Transaction log.

Figure 7: Remote Wipe entry in the Transaction log

Controlling Access Permissions

As mentioned earlier in this article only Exchange Administrators and local administrators on the Exchange server are allowed to use the Microsoft Exchange Server ActiveSync Web Administration tool, but chances are you want to allow helpdesk personnel or other individuals in your IT department access to the tool as well. In order to do so without adding them to the respective groups, you can allow them access by modifying the permissions on the Microsoft Exchange ActiveSync Administration installation folder, which after a default installation can be found under C:\Program Files as shown in Figure 8 below.

Figure 8: Microsoft Exchange ActiveSync Administration installation folder

Here you simply right-click the installation folder then select Properties. On the property page click the Security tab then add the group(s) or user(s) who need access to the tool (Figure 9).

Figure 9: Giving additional groups or users access to the tool

Known Issues

If you receive an HTTP 401 error message when either trying to delete a partnership or initiating a remote wipe, it’s most likely because Integrated Windows authentication isn’t enabled on the Exadmin virtual directory and/or because the MobileAdmin virtual directory doesn’t run under the ExchangeApplicationPool application pool. If this is the case please see MS KB article 916960.
As mentioned in the beginning of this article you may also run into problems when running the tool on an SBS 2003. To resolve these problems see the Troubleshooting section in the Deploying Windows Mobile 5.0 with Windows SBS whitepaper.
Conclusion

In this article which is part 3 in a 5 part article series on Exchange Mobile Messaging, we covered how to install, configure and most importantly use the Exchange Server ActiveSync Web Administration Web tool, which offers you, as an Exchange administrator, features that will help manage and protect the mobile devices in your organization even better than was previously possible.
In Part 4 I’ll uncover the new GAL lookup feature, which surprisingly enough, also is a feature included in Exchange 2003 SP2 and the Messaging and Security Feature Pack (MSFP).

[patris1]

http://www.msexchange.org/tutorials/Exchange-2003-Mobile-Messaging-Part4.html

Part 4 – Accessing the Corporate GAL from your Mobile Device Using GAL Lookup


Introduction

With the new GAL Lookup feature included in the Messaging and Security Feature Pack, you can now lookup contacts in the Global Address List (GAL) on your corporate Exchange Server 2003 SP2 Server(s). Those of you who own a Windows Mobile device which doesn’t have the MSFP installed know that you can only look up contacts in your personal contacts list stored locally on your device. Well actually this statement isn’t completely true, as you can get access to the Global Address Book (GAL) by installing the free Microsoft Global Contact Access add-on on the device. Of course the Microsoft Global Contact Access add-on is not as integrated in the Windows Mobile 5.0 OS as the GAL Lookup, but it’s definitely worth checking out while you wait for a build with the MSFP included for your particular device.
How It Works

GAL Lookup is embedded into the same contact chooser interface as the one used for looking up contacts in the personal contacts list. This means that you can look up contacts in the corporate GAL from within the messaging, phone, calendar and speed-dial menus. This makes it possible for your users to send e-mail messages, meeting requests/invitations, SMS messages to contacts in the corporate GAL. They can even call contacts stored in the corporate GAL.

When you have looked up a contact in the GAL, you also have the option of seeing additional details for the contact, things such as the his title, company etc. (see Figure 1).

Figure 1: Looking up a contact in the corporate GAL

GAL Lookup works by using a new SEARCH verb included in the latest version of the AirSync protocol (version 2.5). This version is, at the time of this writing, only to be found in the Messaging and Security Feature Pack (MSFP). The SEARCH verb makes it possible to look up mail-enabled objects in Active Directory. You can search for these objects by specifying their alias, first name etc. in your query string.

Note:
GAL Lookup is currently limited to searches in the GAL store. My guess is that this limitation will be gone with Exchange Server 2007 and Windows Mobile 6.0 (code-named Crossbow), but as I cannot predict what will happen in future releases, only time will tell.

Below is a list of the properties that can/will be returned when issuing a search request for an Active Directory object using GAL Lookup.

• Alias
• Display Name
• First Name
• Last Name
• Email Address
• Phone
• Title
• Office
• Company
• Mobile Phone

GAL Lookup has been designed in such a way that a property will only be returned if the matching attribute is specified for the user in AD. I think this is very thought through and will eliminate charges for any unnecessary data synchronized over the air.
Sending an E-mail Message to a Contact in the Corporate GAL

Sending an e-mail message to a contact in the GAL can be done in several ways. Here I’ll show you the typical way of doing so.

Open Outlook on your device and then click New in the lower left corner. When you have entered a Subject and typed some text in the message body just as shown in Figure 2 below, click the Menu button in the lower right corner.

Figure 2: Composing a Message

Now choose Find Online (Figure 3) and the device will issue a search request in the GAL on the respective Exchange 2003 SP2 Server .

Figure 3: Finding the respective contact in the GAL

If you know the alias or username of the contact you want to sent the message to, you can also type this in the To: line and click Menu, then Check Names in the context menu (see Figure 4).

Figure 4: Resolving the entered alias or name

When you have found the contact in the GAL, click Select button as shown in Figure 5.

Figure 5

You should now be back in the composing window again. Notice the name as well as e-mail address has been populated in the To: line (Figure 6).

Figure 6: Contact name and e-mail address in the To: line

You can now send the e-mail message, and if you have enabled the DirectPush feature (for more info on the DirectPush technology see part 1 of this articles series), the message will arrive in the recipients mailbox a few seconds later.
Sending a Meeting Request to a Contact in the Corporate GAL

As mentioned earlier in this article it’s also possible to send a meeting request/invitation to one or more contacts in the GAL. This is done by opening the Calendar application and clicking Menu, then select New Appointment in the context menu. When you have filled out the required fields, click Attendees (Figure 7).

Figure 7: Composing a new appointment

You should now be familiar with the user interface, as this is pretty much identical to the one used when finding an e-mail recipient in the GAL. Add the contacts you want to send the meeting request/invitation to, and then click OK (see Figure 8).

Figure 8: Adding the required attendees to the appointment

The Attendees line will now be populated with the contacts you chose in the GAL, as can be seen in Figure 9.

Figure 9: Appointment with Attendees

If you want you can also type in any necessary notes for the meeting by clicking the Notes tab.

Note:
Since a meeting/conference room is nothing else but a mail-enabled user object in Active Directory, you can also book the conference/meeting room when creating the appointment on your device.

When you have sent the meeting request/invitation, it will arrive in the Inbox of the specified attendees within seconds. They will then be able to accept or decline it (see Figure 10), just like it’s possible with a request that has been sent from either Office Outlook 2003 or Outlook Web Access 2003 (OWA).

Figure 10: Meeting request received from a Mobile Device

Dialing a Contact in the Corporate GAL

If you need to call a colleague or another employee in your company, and this person isn’t stored in your personal contacts list, fear not because you can also look up the number of the person in the GAL, or even better call him directly via the GAL Lookup user interface. One way of doing so is to click Contacts in the lower right corner of the Today screen, then click Menu -> Find Online as shown in Figure 11.

Figure 11: Calling a contact not stored in your Personal Contacts List

When you have found the respective contact simply select Call Work or Call Mobile like shown in Figure 12.

Figure 12: Calling a contact in the GAL

Sending an SMS Message to a Contact in the Corporate GAL

I know SMS messages aren’t widely used in the US, but SMS messages are used heavily in Europe, not only among teenagers and for private purposes, but also as a form of communication between colleagues in an organization. If you ask me, an SMS message is a brilliant way of giving a colleague a quick status when you’re attending a meeting or some kind of conference session.
GAL Lookup of course also allows you to send an SMS message to a contact in the GAL. T he method to do this is very similar to what we already went through in this article. You can do it in several ways, but one way is to open the Text Messages application, then clicking New in the screen shown in Figure 13 below.

Figure 13: Composing a new text message

Now lookup the contact in the GAL, then choose Send Text Message as shown back in Figure 12. You should now be back at the text message composing window (Figure 14).

Figure 14: Sending an SMS message to a contact in the GAL

Now send the SMS message. You can of course do the same with MMS messages, but we won't go through the exact steps in this article.
Adding a contact in the GAL to the Personal Contacts List

If you find out that you’ll need to communicate further with someone you just looked up in the GAL in the future, you can add that contact to the personal contacts list stored locally on your device. You do this by clicking Menu -> Add to contacts after you have looked up the respective contact in the GAL (see Figure 15).

Figure 15: Adding a contact in the GAL to your personal contacts list

Conclusion

In addition to their stored contacts, the users in your organization can now access the corporate Global Address List (GAL) over the air from any mobile device that supports version 2.5 of the AirSync protocol (currently only devices with the MSFP installed). Users can search for additional contact details not stored on their device, send e-mail messages, meeting requests/invitations as well as SMS messages to contacts in the corporate GAL. They can even add contacts stored in the GAL to the personal contacts list on their device