your paper notes BULK INSERT (table-by-table) is an exercise in slow ...

one can create/amend a replication pub/sub via

1. the replication wizard from SSMS

2. subsequently modify the config using SSMS property editor [as you do in your paper]

3. use SSMS to script out the pub+sub into a .SQL file (drop then append create)

- and edit [lots] to make it readable, have @variables instead of hardwired strings etc

where #3 is what I suspect most DBA's will do for good practices (DR, HA etc).

Within the .sql script you will find various sprocs like sp_addpublication (all documented fully in BOL) which give you even more fine control to those sprocs, e.g. by params

@sync_method

@post_snapshot_script

@enabled_for_p2p

@compress_snapshot

which are not [fully] exposed by #1 or #2 development stages.

I have not attempted the compress feature [BOL extract below], but if you had a few large tables (and didn't justify the .BAK approach in the paper) it would be worth investigating

- might be an exercise in lots faster !

[ @compress_snapshot= ] 'compress_snapshot'

Specifies that the snapshot that is written to the @alt_snapshot_folder location is to be compressed into the Microsoft CAB format. compress_snapshot is nvarchar(5), with a default of FALSE. false specifies that the snapshot will not be compressed; true specifies that the snapshot will be compressed. Snapshot files that are larger than 2 gigabytes (GB) cannot be compressed. Compressed snapshot files are uncompressed at the location where the Distribution Agent runs; pull subscriptions are typically used with compressed snapshots so that files are uncompressed at the Subscriber. The snapshot in the default folder cannot be compressed.