Before upgrading from one edition of SQL Server 2005 to another, verify that the functionality you are currently using is supported in the edition to which you are upgrading. For more information, see the section "SQL Server 2005 Replication Features" in the topic Features Supported by the Editions of SQL Server 2005.

In previous versions of SQL Server, agents ran, by default, under the context of the SQL Server Agent service account. SQL Server 2005 allows fine-grained control over each account under which the replication agents run and make Windows Integrated connections to databases and other resources; a different account can be specified for each agent. For more information, see Security Considerations for Replication and Replication Agent Security Model.

The new security model has the following implications for upgrading and running more than one version of SQL Server in a topology:

• Replication scripts created from SQL Server 2000 or SQL Server 7.0 should be upgraded for SQL Server 2005 in order to take advantage of security enhancements. For more information, see How to: Upgrade Replication Scripts (Replication Transact-SQL Programming).
  
• A Distributor or Subscriber upgraded from a previous version of SQL Server to SQL Server 2005 continues to run under the SQL Server Agent account and likely has more privileges than it requires. After upgrade we recommend that you specify separate accounts for the agents with the appropriate minimum privileges. To specify separate accounts:
  
  1. Script out the publication and subscriptions.
     
  2. Make changes to the scripts. For more information, see How to: Upgrade Replication Scripts (Replication Transact-SQL Programming).
     
  3. Drop the publication and subscriptions. For more information, see Publishing Data and Database Objects and Subscribing to Publications.
     
  4. Recreate them using the modified scripts.
     
  For information on the privileges required by agents, see Replication Agent Security Model; for information on managing logins and passwords, see Managing Logins and Passwords in Replication. New replication configurations created after an upgrade requires specific account configuration for each replication agent.
  

  Note:

  Any agents configured to use SQL Server Authentication for local database connections is changed to use Windows Authentication. Local connections are those connections made by an agent to an instance of SQL Server running on the same computer as the agent. For example, the Merge Agent for a pull subscription runs at the Subscriber, so the connections it makes to the Subscriber are local connections.

• Participants in a replication topology running previous versions of SQL Server retain the previous replication security model unchanged. For example:
  
  • A pull subscription to a Subscriber running SQL Server 2000 or SQL Server version 7.0 does not use the new security model because the Merge Agent or Distribution is created at the Subscriber.
    
  • A push subscription from a Distributor running SQL Server 2005 to a Subscriber running SQL Server 2000 or SQL Server version 7.0 uses the new security model because the Merge Agent or Distribution is created at the Distributor.
    
  • A Publisher running SQL Server 2000 or SQL Server version 7.0 with a Distributor running SQL Server 2005 does not use the new security model (for the Snapshot Agent, Log Reader Agent, or Queue Reader Agent) because the agents are created in the context of the publication database.
    

After upgrade, run the Snapshot Agent for each merge publication and the Merge Agent for each subscription to update replication metadata. You do not have to apply the new snapshot, because it is not necessary to reinitialize subscriptions. Subscription metadata is updated the first time the Merge Agent is run after upgrade. This means that the subscription database can remain online and active during the Publisher upgrade.

Merge replication stores publication and subscription metadata in a number of system tables in the publication and subscription databases. Running the Snapshot Agent updates publication metadata and running the Merge Agent updates subscription metadata. It is only required to generate a publication snapshot. If a merge publication uses parameterized filters, each partition also has a snapshot. It is not necessary to update these partitioned snapshots. (In SQL Server 2000, parameterized filters were referred to as dynamic filters, and partitioned snapshots were referred to as dynamic snapshots).

Run the agents from Microsoft SQL Server Management Studio, Replication Monitor, or from the command line. For more information about running the Snapshot Agent, see the following topics:

• How to: Create and Apply the Initial Snapshot (SQL Server Management Studio)
  
• How to: Start and Stop a Replication Agent (SQL Server Management Studio)
  
• How to: Create the Initial Snapshot (Replication Transact-SQL Programming)
  
• Programming Replication Agent Executables
  

For more information about running the Merge Agent, see the following topics:

• How to: Synchronize a Pull Subscription (SQL Server Management Studio)
  
• How to: Synchronize a Push Subscription (SQL Server Management Studio)
  
• How to: Synchronize a Pull Subscription (Replication Programming)
  
• How to: Synchronize a Push Subscription (Replication Programming)
  

After upgrading SQL Server in a topology that uses merge replication, change the publication compatibility level of any publications if you want to use new features. For more information, see Using Multiple Versions of SQL Server in a Replication Topology.

The Web synchronization option for merge replication requires that the SQL Server Replication Listener (replisapi.dll) be copied to the virtual directory on the Internet Information Services (IIS) server used for synchronization. When you configure Web synchronization, the file is copied to the virtual directory by the Configure Web Synchronization Wizard. If you upgrade the SQL Server components installed on the IIS server, you must manually copy replisapi.dll from the COM directory to the virtual directory on the IIS server. For more information about configuring Web synchronization, see Configuring Web Synchronization.

To ensure replication settings are retained when restoring a backup of a replicated database from a previous version: restore to a server and database with the same names as the server and database at which the backup was taken.

Concepts

Other Resources

Help and Information