Filtering out the backup directory will result in critical files not being replicated and can cause instability within the Revit product itself.
The Revit product suite by Autodesk supports simultaneous access and modification to models via a functionality known as Worksharing. When Worksharing is enabled in a Revit model, work is coordinated through a master copy of the model file known as the Central file. The Central file is used to store the current ownership information for all entities and worksets in the project, and acts as the distribution point for all changes published to the file. When operating in Worksharing mode, users work on a local copy of the Revit model and can save changes to the Central file so that other users can see their work.
When using Revit with the WAFS system, the Central file and its ancillary files are stored within WAFS Jobs and efficiently replicated to applicable sites. This includes optimized transfer of not only Central files during Save to Central operations, but also the other files used by Revit when performing Worksharing operations. These additional files are found in the <Central files>_backup directory created along with the Central file and include files such as the eperms.dat and wperms.dat files that are used to manage entity and workset borrowing coordination.
|
|
Filtering out the backup directory will result in critical files not being replicated and can cause instability within the Revit product itself. |
Thus, when using Revit with the WAFS system, users will not only see an improvement in data transmission during Save to Central and Reload Latest operations, but also for general editing activity during which Revit must access the permissions files.
Prior to using Revit with the WAFS System, it is highly recommended that Revit users and WAFS system administrators familiarize themselves with the concepts of multi-user collaboration within Revit using Revit Worksharing. Various Revit white papers can be downloaded from the Autodesk Website. (You will need Adobe Acrobat Reader to access the files.)
The following articles are of particular interest:
The white paper entitled “Multi-user Collaboration with Autodesk Revit Worksharing” specifically addresses the topic of Revit Worksharing.
The technical note entitled “Model Performance Technical Note” discusses performance considerations and guidelines for working with Revit, including use in Worksharing environments.
An adjustment must be made on user workstations for users that will be working on work-shared Revit models being replicated by the WAFS system. The modification requires the creation of a new drive letter mapping using the Windows SUBST command.
When Revit creates a Central file, it stores the path of the Central file within the Central file and associated local files. This path is used by the Revit workstations in conjunction with the local copies of the Central file to identify where the Central file resides for actions such as Save to Central, Reload Latest, and borrowing.
When replicating Central files via the WAFS system, the Central files will be located on different file servers at each site. Thus, the UNC path will be different at each site and will result in Revit failing to locate the Central file when working in the work-shared mode. Supposing there are 2 offices, users at Office A will access a shared drive on FileServerA and users at Office B will access a shared driver on FileServerB. If a user at Office A creates a new Central file, the Central file will internally store a UNC path with \\fileservera\Revit Projects. When a user at Office B accesses the file, which has been replicated by WAFS to FileServerB, Revit will expect to see a UNC of \\fileserverb\Revit Projects and will issue a warning that the Central file has been relocated.
Typically, this is resolved by creating a mapped drive at each site using the same drive letter. However, when creating a Central file, Revit internally converts the Central file path to a UNC format path and stores it as such, thus defeating the purpose of using the same drive letter.
To rectify this issue, user workstations must instead be configured to create a new drive letter using the SUBST command. The SUBST command simply creates a new drive letter that maps to an existing drive or a UNC path. However, due to the nature of the SUBST command, Revit is unable to convert drive letters created using the command to UNC paths. Ultimately, this prevents Revit from storing a UNC path internally and it will instead store and use the proper drive letter.
On end-user workstations, use of the SUBST command to create the appropriate drive can be performed manually from a command prompt or using a batch file, or can be automated using login scripts.
On Windows XP-based and Vista-based user workstations the drive mapping can be created from the command line as follows:
SUBST <New Drive Letter>: <UNC to Shared WAFS Replicated Folder on File Server>
If you are creating a new drive letter M and the WAFS Replicated Folder is shared from the DENVERSRV File Server using the path RevitProjects, then the following command would be used:
SUBST M: \\DENVERSRV\RevitProjects
End-users at all sites would now use the new M: drive letter when access work-shared Revit Central files.
|
|
To view the usage of the SUBST command, at a command prompt, type: SUBST /? |
On Windows 2000-based user workstations the SUBST command does not support use of UNC paths. Instead, a normal drive mapping must first be established to the shared WAFS Replicated Folder and then this drive is used in place of the UNC path in the SUBST command. From the command line, a normal mapped drive can be created using the net use command.
The normal drive mapping may be created from the command line as follows:
NET USE <Drive Letter>: <UNC>
For example, if the WAFS Replicated Folder is shared from the DENVERSRV file Server using the path RevitProjects, then the following command would be used to create a new mapped drive N:
NET USE N: \\DENVERSRV\RevitProjects
Once the drive mapping has been established, the SUBST command can be used to create the drive that must be used when accessing the Revit Central files. The drive mapping can be created from the command line as follows:
SUBST <New Drive Letter>: <Existing Mapped Drive Letter>:
For example, if you are creating a new drive letter M and the existing mapped drive is N, then the following command would be used
SUBST M: N:\
End-users at all sites should now use the new M: drive letter when access work-shared Revit Central files.
|
|
To view the usage of the net use command, at a command prompt, type: NET USE /? |
Note: A side effect of using the SUBST command is that the SUBST drive letter initially appears in Windows Explorer as "Disconnected Network Drive." This is nothing to be concerned about and the drive can simply be renamed, if desired.
To ensure the proper operation of Revit when used in Worksharing mode in a WAFS environment, certain WAFS Job settings must be configured in a specific way.
These settings may be different from the desired or typical settings used when working with other types of projects. Because of this, it is highly recommended that Revit projects be located in their own specialized WAFS Job. This allows for specialized configuration of Job settings without affecting the standard workflow of other projects.
Replicated Data Access Options: To ensure proper coordination of changes in a work-shared environment the WAFS System must prevent the possibility of simultaneous modification of the work-shared Revit Central file at the various Agent locations. To ensure this behavior we strongly recommend setting the Replicated Data Access options for the Job as follows:
When Agent is not running: Prohibit access
When the Agent is offline (disconnected from the Vault): Read-only access
Filters: The files *.tmp and *.slog are used by the WorkSharing Monitor. You do not need to filter out these files; however, if you are not using Worksharing Monitor, filtering out those files would improve Revit performance.
|
|
Filtering out the backup directory will result in critical files not being replicated and can cause instability within the Revit product itself. |
Configuration changes must be made to WAFS' configuration to take full advantage of the performance improvements: Bandwidth throttling must be set to high.
Customers with connections of less than 1MB should monitor for bandwidth saturation after upgrade and then adjust to Auto or Low as needed.
For editing permissions (Borrowing) to function correctly in Worksharing mode, all users working on a model must ensure they have configured a unique username within the Revit configuration settings.
When working with Revit in Worksharing mode, Revit coordinates editing permissions from the multiple users based on the configured username. The username for each user operating within the same model must be unique. If multiple users mistakenly operate on the model using the same username, Revit may fail to ensure only one user can borrow an entity or workset at a time.
Revit will automatically use the username of the authenticated operating system user when Revit is initially run on the workstation. However, be aware that Revit will continue using this initial username on subsequent runs even when a different user is logged into the workstation. Please refer to the Revit user guide(s) for more information about, and the importance of, usernames in relation to work-sharing.
When performing a Save to Central operation, Revit offers users the option to compact the Central file to reduce the amount of disk space it consumes.
Compaction of the Central file is supported by the WAFS system; however, it is recommended that users not perform the compaction on every Save to Central operation. This is recommended because one of WAFS primary features for providing performance improvements for the Save to Central and Reload Latest actions is its delta technology. This technology allows the WAFS system to transfer only the changed portions of the file. The Compact Central File option causes the majority of the Central file’s contents to change. When this occurs, the benefits of the delta technology are generally reduced. However, when Central file compaction is required due to file size, WAFS will still be able to make use of other optimizations, such as data compression, when transmitting the updated file.
When the Compact Central File option is used, users at the other physical locations may experience a longer than usual delay in access to the Central file while the larger amount of data is replicated by the WAFS software.
The Revit Worksharing monitor provides monitoring and statistical capabilities to end-users working with work-shared Revit Central files. Typically it will notify users of edit requests from other users, track edit requests sent to other users, keep users apprised of other user’s actions and the progress of those actions, and provide notifications of system events (such as an failed edit request).
Features of Worksharing Monitor
Display of users and their current workspace (Local or Central)
Progress of users actions (Saving to Central)
Display of currently pending edit requests
System Notifications
System Performance
|
|
Worksharing Monitor is unaware of WAFS transfer activities. |
When operating in worksharing mode, users work on a local copy of the Revit model and can save changes to the Central file so that other users can see their work. The local file is the same size as the Central file and can exponentially increase the storage space required for a project when multiple local files are saved on the network. You can control how often Revit's worksharing display modes and editing requests are updated in model views, to reduce network traffic.
To change the worksharing update frequency in Revit 2012
Click R logo, then click Options.
In the Options dialog box, click the General tab.
In the Worksharing Update Frequency area, move the slider all the way to the left for manual updates only. When set to manual, display mode information is only updated when you borrow elements; worksharing display does not generate network traffic.
Click OK.
Some applications save numerous versions (i.e., more than 32) of previous versions of files (e.g., Microsoft Outlook .pst files, AutoDesk Revit Files, Automatic ACL Replication files), causing the Vault to fill up very quickly. If the WAFS Vault is filling up with large numbers of previous versions of files, in WAFS version 3.6.2, you can enable a cleanup algorithm to automatically remove the previous versions by setting the "enbSpecialPass" Windows Registry key to 1 to enable a cleanup algorithm (0 to disable the algorithm).
To add the key and enable the cleanup algorithm
On 32-bit systems:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Availl\Availl Server\Settings]
"enbSpecialPass"=dword:00000001
On 64-bit systems:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Availl\Availl Server\Settings]
"enbSpecialPass"=dword:00000001