Notes DocLinks may be converted to Dynamic Links as they are migrated to SharePoint. These are actually URLs to a Redirector Page, which is responsible for redirecting users to the current location of the target document. (At any given time, some documents will have been migrated to SharePoint lists or libraries whereas other may still exist in Notes only.)
By default, Dynamic Links in migrated documents will reference the Redirector Page on the same SharePoint server. In rare cases, you may want to specify a Redirector Page on a different server instead. (This setting impacts future migrations only. To change the Redirector Page location in documents you have already migrated, use the Link Tracking Updater/Finalizer tool.)
The Link Tracking Service keeps track of each migrated document in a SQL Database, known as the Link Tracking Database. This database is created when you first install Migrator for Notes to SharePoint Services.
Over time, your Link Tracking Database may contain links to documents that were subsequently deleted or were written using an older version of Migrator for Notes to SharePoint. Analyzing all the links in the database before updating or finalizing your links is strongly recommended.
The Link Tracking Database Updater allows you to update the locations of your migrated documents in the Link Tracking Database. This will be useful if the locations of your migrated documents have changed (for example, you may have changed the external host name of your SharePoint server, changed the path for a SharePoint site, or moved your content database to a different server). You can also preview the changes that will take place in the Link Tracking database, then update to commit the changes to the Link Tracking Database. You can view the log files and see the status of the update.
You can use this tool to update or permanently replace all Dynamic Links in a set of migrated documents. This works for links in SharePoint List Items, SharePoint Pages, InfoPath documents, Word documents or any other SharePoint target you chose to migrate to. A secondary reason might be to change the location of your Redirector Page.
Decide what you want to do with Dynamic Links that point to migrated documents. The most common is to replace them with direct links to the migrated documents (that is, their new URLs in SharePoint). Since this is a permanent, irreversible operation, we refer to it as "Finalization".
You also need to decide what you want to do with Dynamic Links that point to un-migrated documents. Our recommendation is to leave them the way they are, in case you want to migrate the linked-to documents later. If you are really sure that those documents are going to stay in Notes, you can finalize those links with the original Notes/Domino URLs.
The use of the shared folder during data transfer is optional. Even if it is configured on the server, it can be turned off by any of the clients. If it is turned off, the client will transmit the data as encrypted bits in memory which can be a slower process. For migrations using the Console, the option to turn of the shared folder is located in the SharePoint tab of the Global Options window. For migrations using the Designer, the option is located in the SharePoint Options tab of the Global Options window.
The user running the client will need read/write access to this folder. The Import Service accesses the files by impersonating the user specified in the SharePoint authentication section of the Global Options window. This user needs to have read/write access to the shared folder as well. If you are using Windows authentication, then the same identity being used when running the client ("Joe") is the same identity that the server will use to access the files ("Joe"), so only "Joe" needs to have read/write access to this folder. If you are using different SharePoint credentials ("Servername\Sally"), then the Import Service will impersonate "Sally" when accessing the shared folder, so "Sally" needs to be given read/write access to this folder as well.
The files that are copied to the shared folder are automatically deleted by the Import Service once the data transfer is complete. If the Import Service in terminated in an unexpected way (e.g., using IISReset or rebooting the server while a Import Service session is active), then the Import Service will not have had an opportunity to delete the shared folder for that session. The administrator will need to manually delete these "orphaned" session subfolders in these cases.