Link Translation (LT) is not a new function in ISA Server 2006, but it is the first implementation that is fully supported. The LT function is a Swiss army knife in a lot of situations. See the following notes from the field, where we solved a very complex business problem with it. For more information about LT see http://www.microsoft.com/technet/isa/2006/link_translation.mspx
· Big branch office environment where the leased line between the branches and headquarter is very limited. The average bandwidth is less than or equal to 128 kbit/sec.
· We have a SharePoint Portal Server infrastructure at headquarters. The main purpose of this SharePoint portal is to help the team work between the HQ and branch users.
· In the SharePoint infrastructure we store a huge number of documents. The average document size is around 2-5 MB.
· The SharePoint infrastructure will be accessed from the branch offices through WAN connections. As a general rule the bandwidth of the WAN connection is low and utilized.
· The goal is that the branch office users use the WAN line with the least possible usage, in a way that the document stored in the SharePoint document libraries will be accessible through their own branches and not through the WAN lines.
· The topology is as shown:
The first question to be decided during the planning of the new concept is the protocol to be used to reach the document stored by their local servers. Considering the technical possibilities, it is theoretically possible to access the data stored on the local servers using HTTP or SMB traffic. We decided to discard the HTTP protocol because it is too complicated to manage a few hundred IIS servers (the customer has about 500 branches). Therefore we analyzed only the access through an SMB-based solution. The consequence of this decision was that we could separate the tasks to three main parts:
· Dump the data from the SharePoint document library to the file system.
· Distribute the data from the file system to the branches
· Redirecting the client requests to the local server.
The document will discuss the solution based on this task definition.
The recommended solution will work properly only if the following requirements and prerequisites exist:
· The solution requires that the users access the SharePoint servers through ISA Server 2006.
· The users in the branch offices can’t make changes (document upload, document modify, document delete) to the affected document libraries.
· The documents will be delivered to the branch offices once a day, at night.
· It is necessary to unambiguously determinate the document libraries that will be used with the service.
· We suggest using short document library names (less than 15 characters) without high-bit or space characters.
· The infrastructure services must be configured to include the document library in the scope of the service, when a new document library will be created.
It is necessary to mirror the documents from the SharePoint document libraries to the file system with a custom application because the DFSR (described later in this posting) technology supports replication only from the file system. The requirements for this application:
· The source SharePoint document libraries used for mirroring and the destination Windows folders must be configurable (for each SharePoint document library)
· Only the modified documents should be copied during the mirroring (the metadata changes cannot count as a document change)
· The deleted documents must be deleted from the file system too
· The mirroring is scheduled (and does not occurs when the change is made)
Because this application is not part of the SharePoint system custom development is required.
After we moved the documents from the SharePoint document library to the file system, based on that method and tool described in the previous section, the next goal is to deliver and synchronize the content to the branch servers. The best solution to replicate a large amount of data in a branch office environment with maximum efficiency and with minimal bandwidth usage is the DFSR technology. For more information about the Windows Server 2003 R2 DFSR solution please see our DFSR Technology center at http://www.microsoft.com/dfs
The main parameters of the DFSR based file replication technology that we use for this service are:
· We create a DFSR Group dedicated for the service with a dedicated Replicated Folder.
· We create a two-way, hub and spoke replication topology.
· Every affected branch office server will be a member of the Replicated Group and will be used in the replication.
· The dedicated Replicated Folder will be shared with everyone with Read permissions automatically on all servers using DFSR.
· Every folder that represents a document library will be shared with the same name and with Read permissions for everyone in the file system.
· The document replications will be monitored by MOM.
When the clients browse the SharePoint based document libraries, the SharePoint server sends an ASPX page. This page is stored on or created by the SharePoint server. The returned ASPX page contains the URLs and links of the content what is stored in the document library. By default these links refer to the documents that are uploaded to the SharePoint server. For example: https://SharePointfarm.contoso.com/Test/Test.doc where the /Test mean the document library called test and the Test.doc means the document that is stored in the Test document library.
In the response for the client request the https://SharePointfarm.contoso.com must be changed to a universally translatable name, using ISA Server 2006 Link Translation. This universally translatable name must be compliant with the following requirements:
· The name must be resolvable in every branch office where the application is used.
· The name must point to the branch server that is at the same site as the client.
· The name must provide redundancy and load balancing if there are multiple servers are available at the branch level.
· The result of the name resolution must be manageable in the highest degree at the branch level.
· The name must be usable for the Internet Explorer and the Office applications which work as SharePoint clients.
We recommend creating a DFS Namespace service with a unified namespace for the branch environment. With the usage of the unified DFS Namespace, it is possible to change the original URL for the same name (e.g.: \\contoso.com) in every situation, and this will point to the local domain controller at the same time.
The figure below demonstrates the whole process of the suggested approach:
The explanation of the process in the picture:
1. In this step the data from the SharePoint document libraries will be dumped to the server that is functioning as a file server. After that the DFSR function will replicate the content to the local servers in the branch offices. By default the process is repeated every 24 hours, but it is possible to schedule it more often or manually start it at any time.
2. The hosts from the internal network start to open the SharePoint document library from the branch office through ISA Server 2006 computers, using the https://SharePointfarm.contoso.com address.
3. The ISA Server 2006 computers relay to the SharePoint servers. The members of the SharePoint farm reply to the request and send the response to the ISA Server 2006 computers.
4. The ISA Server 2006 computers change the links based on the link translation mapping table and modify the HTTP response that they received in step 3. After link translation, the links are changed to file://\\contoso.com. Yes it is possible to replace the <a href> type links in this format, where the link points to the different protocols (for example: the original protocol was https:// and the replaced protocol now is file://)
5. The ISA Server 2006 computers send the modified response back to the workstation as an answer to the request in step 1. The response contains the links modified to file://\\contoso.com.
6. The workstation opens the link in the response (from step 5), which points to the local server, and downloads the content synchronized at step 1.
Very interesting. But did you have to do anything special in the link translation rule to change from https:// to file:// ?
Can you give an example of the actual link translation configuration, as this is the heart of this article?