SqlCeReplication.HostName Size Limit Fix?

We are attempting to improve our merge replication process between our SQL Server 2005 server and SqlCe Mobile 3 client by switching to Data Partitions. We are using IIS as a proxy to SQL Server 2005 running on a different box using a DOMAIN account.

We've setup row filters to use HOST_NAME() and have set the option "Automatically define a partition and generate a snapshot if needed when a new Subscriber tries to synchronize" to true in the Data Partitions options under the publication's properties in SQL server management studio.

If I use a .HostName value of "1234", everything works fine. A subdirectory is created under a our publication's folder in the shared replication directory that relates to the host_name. Data is copied to the device and can be observed through query analyzer that the data is in fact filtered properly.

However, when using a .HostName based on the GetDeviceUniqueID (which results in '3D321F7212B2AD2CC824954662B9023441BB2D20'), replication works sometimes and sometimes fails with "The merge process was unable to deliver the snapshot to the Subscriber. If using Web synchronization, the merge process may have ben unable to create or write to the message file. [etc]". The final HRESULT is 80045017.

While this error indicates a permission problem, there were no permission problems when creating the "1234" partition. In researching the problem, I ran across KB905395 which states:
Limitations on the HostName property and the Subscriber-requested snapshotIf you try to initialize a SQL Server Mobile Edition subscription by using a filtered HostName property, initialization fails. This problem occurs when the value that is supplied for the HostName
property contains more than 12 characters. To work around this problem,
disable Subscriber-requested snapshot delivery at the Publisher. You
can also use a value for the HostName property that contains fewer than 12 characters.

====

This seems to be consistent with what we've observed (which actually led to the "1234" test). Does anyone know if a fix for this exists? Has anyone else run across this issue? I saw a previous post from March that did, but never got resolved. However, the KB article above was posted in March - hmmm...

This is an existing application and filtering based on the device's id is ingrained in the application. Changing it now would be large undertaking.

Regards,
Santino Lamberti
Senior Software Engineer
Launch Technologies, Inc.