So in a previous thread I discovered that in order to actually subscribe to any publication, the publisher needs to be a well-known network name, requiring DNS resolution. You can't simply point a SQLExpress instance at an ip address\instance and have it resolve the communications.
So then there is also this alternative synchronization method where by you can setup an https website that controls the synchronization of data.
So I'm guessing that the "assumed" methodology for these operations goes as follows:
1) Publishing SQL Server instance requires a resolvable DNS name.
2) Setup merge publication.
3) Setup SSL on IIS.
4) Setup a network share to house the synchronization data.
5) Setup Web synchronization and have it implement a virtual directory under the new SSL arrangement in IIS and use the network share specified in step #4.
6) Turn on Web access for the publication.
7) A client computer, logged into the domain, subscribes to the publication.
8) The client computer's subscription is altered to use web synchronization.
9) Code is written to enable the web synchronization process to execute.
10) A smart client may now disconnect from the domain and continue to use the subscription offsite using the SSL-enabled web synchronization.
Issues I'm still having include:
* authentication into the https web synchronization
(not SSL, that's working fine)
unless I use an Administrator login with Basic (open passwords!),
I get "Access Denied" on the replisapi.dll?diag test page
I almost think there needs to be a separate tool to manage web
synchronized merge replication installations. Like a Client Tool and a Server Tool.
This tool would clearly help you manage all of these operations and clearly help
you diagnose any problems, including authorization.
Anyway, can someone verify that 1 through 10 are accurate and that I haven't missed anything?
Thanks,
David Cornelson
So then there is also this alternative synchronization method where by you can setup an https website that controls the synchronization of data.
So I'm guessing that the "assumed" methodology for these operations goes as follows:
1) Publishing SQL Server instance requires a resolvable DNS name.
2) Setup merge publication.
3) Setup SSL on IIS.
4) Setup a network share to house the synchronization data.
5) Setup Web synchronization and have it implement a virtual directory under the new SSL arrangement in IIS and use the network share specified in step #4.
6) Turn on Web access for the publication.
7) A client computer, logged into the domain, subscribes to the publication.
8) The client computer's subscription is altered to use web synchronization.
9) Code is written to enable the web synchronization process to execute.
10) A smart client may now disconnect from the domain and continue to use the subscription offsite using the SSL-enabled web synchronization.
Issues I'm still having include:
* authentication into the https web synchronization
(not SSL, that's working fine)
unless I use an Administrator login with Basic (open passwords!),
I get "Access Denied" on the replisapi.dll?diag test page
I almost think there needs to be a separate tool to manage web
synchronized merge replication installations. Like a Client Tool and a Server Tool.
This tool would clearly help you manage all of these operations and clearly help
you diagnose any problems, including authorization.
Anyway, can someone verify that 1 through 10 are accurate and that I haven't missed anything?
Thanks,
David Cornelson