[cvs] [Wiki] changed: Project/ActiveSync

Sat Apr 24 17:26:03 UTC 2010

mrubinsk  Sat, 24 Apr 2010 13:26:02 -0400

Modified page: http://wiki.horde.org/Project/ActiveSync
New Revision:  1.48
Change log:  git rid of a big todo =)

@@ -17,11 +17,11 @@
  Integrate the Z-Push library into Horde. Provide the ability for  
Horde to provide over the air synchronization of email, contacts, and  
calendar data to devices such as the iPhone/iPod Touch, Android and  
any other system supporting !ActiveSync. This implementation supports  
Microsoft !ActiveSync protocol versions up to 2.5 - the version  
implemented by Microsoft Exchange 2003.

  ++ Trying it out

-The !ActiveSync code has been merged into git master, but is not  
active by default. You should be aware that this code is still very  
experimental. While it mostly works for me in my tests, on my test  
devices, there are likely still many bugs. It may work, it might not,  
or it might make your iPod grow legs and run for higher ground. You  
have been warned.
+The !ActiveSync code has been merged into git master, but is not  
active by default. You should be aware that this code is still  
considered experimental. While it mostly works for me in my tests, on  
my test devices, there may still be bugs. It may work, it might not,  
or it might make your iPod grow legs and run for higher ground. You  
have been warned.

-To activate the server, you need to enable it in Horde's  
configuration. You will see an !ActiveSync tab.
+To activate the server, you need to enable it in Horde's  
configuration, on the !ActiveSync tab. There are two possible state  
drivers, a file based driver based on Z-Push's //diff// backend, and a  
Horde_History based driver that is orders of magnitude more efficient  
for synching with Horde.  The file based state driver is included as a  
state driver for those using the Horde_ActiveSync library as a  
solution for other groupware backends. You should use the History  
driver with Horde. You will need to create the SQL tables that the  
driver uses using the //horde/scripts/sql/horde_activesync.sql//  
creation script.

  You will also need to configure your webserver to redirect the URL  
Microsoft-Server-ActiveSync to your horde/rpc.php file. How you do  
this depends on your webserver and it's configuration. For Apache,  
something like:
  <code>
  Alias /Microsoft-Server-ActiveSync /var/www/html/horde/rpc.php
@@ -60,20 +60,13 @@
  +++ Provisioning/!RemoteWipe

  Provisioning allows devices to be more tightly registered with a  
particular server. It enables the server to be able to send policy  
settings to the device. These policy settings include things like  
requiring a PIN to unlock the device, the complexity of the PIN  
required, the number of failed login attempts allowed etc...  
Additionally, it enables devices to be remotely wiped so that if a  
device is lost or stolen, the user or administrator can request the  
device to be wiped.

-As of yet, no user interface yet exists for initiating a remote wipe,  
but the functionality is there.  If you want to test this you need to:
+As of yet, no user interface yet exists for initiating a remote wipe,  
but the functionality is there. To manually test this, you need to set  
the value of the device_rwstatus field from 0 to 2 and change the  
value of device_policykey to 0 in the horde_activesync_device table  
for the device you want to wipe. **PLEASE MAKE SURE YOU KNOW WHAT YOU  
ARE DOING - THIS RESETS SOME DEVICES TO FACTORY DEFAULTS**

-# Open up the device's state info file. This is in your state  
directory and is named info-{deviceidgoeshere}.
-# Set the 'rwstatus' value from 0 to 2.
-# Change the policykey to 0 (actually, any value other then the  
current policykey would work).
-# Save the file
-
-The next time the device attempts to request a command other then  
PING or OPTIONS, it will be wiped. DO THIS AT YOUR OWN RISK!!! After  
it is wiped, if you wish to allow the device to connect to your server  
again, you should remove the info-{deviceidgoeshere} file so it can be  
rebuilt. If you do not remove this file, or at least set the value of  
rwstatus back to 0, the device will continue to be wiped each time it  
reconnects to the server.
+The next time the device attempts to request a command other then  
PING or OPTIONS, it will be wiped. **DO THIS AT YOUR OWN RISK!!!**  
After it is wiped, if you wish to allow the device to connect to your  
server again, you should remove the entry in the device table for the  
device so it can be rebuilt. If you do not remove this entry, or at  
least set the value of rwstatus back to 0, the device will continue to  
be wiped each time it reconnects to the server.

  ++ Rough list of issues/todos/development notes in no particular order
-
-* Horde_History state driver. Currently, !ActiveSync support uses a  
file-based state driver to persist the PIM state so we know what  
changes. This is a refactored implementation of what the Z-Push  
library does. For Horde, this is inefficient, as we have the data  
needed to know what has changed and when. Once the majority of the  
feature set is working, a Horde_History driver should be written to  
replace the file based driver when syncing contacts, calendar, and  
todo data. We might still need it if/when push email is implemented.  
The backend drivers are able to specify a particular state storage to  
enable this functionality if it is needed.

  * Need to implement ghosted properties / SUPPORTED tag. Currently,  
each message that is sent from PIM -> Server is overwritten and  
replaced with only what the PIM sends. It's possible for some PIMS to  
ghost contact and calendar properties so that only the supplied tags  
are changed and missing, ghosted, properties are retained on the  
server.  When a PIM supports this, it sends a SUPPORTED tag with  
children representing the NON-ghosted properties. The absence of the  
SUPPORTED tag would indicate that any property not transmitted should  
be handled as a ghosted property.

  * Implement more recent protocol version support - version 12 or  
maybe 12.1 (Exchange 2007??) should be fairly non-disruptive. Version  
12 would get us more atomic policy settings, local wipe rules, as well  
as the ability to send the policy settings to the client as the more  
compact wbxml. 14 (Exchange 2010?) would probably be lots more work as  
it does away with PING, using SYNC for waiting for changes instead.

