New in AM2004b: Administration

Domain, Authentication and Security Issues

Bug 17726: "NT4 as domain controller for NT5 can work incorrectly", RefNum SU040219165648

When having a domain controller hosted on a Windows NT4 server and EDM Server hosted on Windows 2000 Server or Windows 2003 Server, a request to the domain controller might fail. This has been resolved.

Bug 17613: "Reporting doesn't work on NT4", RefNum AB040130155218

When attempting to generate a report on Windows NT4, this operation failed with "Interface is unknown" error. The problem was in getting information from the domain controller hosted on a Windows NT4 Server. This has been resolved.

'Unlock all documents' command

At times, an administrative operation may require all documents in the vault to be unlocked. For example, it is not possible to change the 'Work Isolation Mode' while certain documents are locked. For situations like these, a wizard has been added to the AM-Administrator to unlock all documents in a vault. This wizard should be used with caution, because it will unlock all documents for all users.

Before using the 'unlock all documents' function, please verify that no users are working in the vault. Users that have recently modified files, can use the 'Synchronize Now' command to ensure that the latest content has been uploaded to the vault.

Some background on document locking

Documents are locked when the a user has a writable copy of the document in his or her Local Workspace. The lock is intended to prevent any conflicts between the Local Workspace and the documents in the vault. This ensures a correct synchronization of the files in the Local Workspace with the vault at any time.

When you unlock a document, you implicitly discard any modifications that may exist in a Local Workspace. In a normal situation, documents are unlocked by the client application that also manages the Local Workspace. In this case the client will first upload any modified files from the Local Workspace to the vault.

When documents are unlocked from another machine (the server) the workspace can not be synchronized. Any changes to local files after the latest synchronization will then result in a conflict.

'The file is modified outside the vault.'                          

The user will have to resolve the conflict by selecting one of two option for each document:

• Upload the modified file to the Vault.
• Discard the local modification (update from vault).

Restoring a Vault Backup

There is a special situation after restoring a backup of a vault. The document locking information in the restored vault dates back to the moment the back up was created. The Local Workspace content of the users may have changed since that time.

If a document was locked for a user at the moment that the back up was created, any corresponding writable files in the users Local Workspace will be automatically uploaded to the restored vault. In most situations, this is the desired behavior. If you are not sure about this, the automatic upload can be prevented by unlocking all documents after the vault restore. This will force the users to upload the modified documents manually (=resolve the conflicts, see above).