Choose from the following topics:
The following caveats and open issues remain in this release. Recommended work-around is provided where possible.
If hard links are known to be in the subclient content, use as a workaround either Change Journal or Classic Scan when running a Windows File System backup.
When using only full and differential backups, expect any differential backups after a synthetic full to continue backing up all files that have changed since the first full (rather than all files that have changed since the synthetic full).
If you combine file level subclient content (file.*, file*.txt, etc...) with a subclient filter defined with any wildcards, the subclient filter will not be applied. To work around this, use directory level wildcards to define subclient content.
During the data protection process, default subclients do not automatically filter wildcard subclients that use range ([ ]) and/or negation (!) wildcards for content. The defined range that the wildcard subclients backs up must be manually filtered for the default subclient.
To work around this, define subclients with directories, wildcards that result in directories, or filter these individual files/wildcards from the default subclient.
When upgrading from Windows 2000 to Server 2003, or using any account other than the LOCALSYSTEM account, the upgrade program may attempt to back up RSM even if it is not installed on the client computer. This will result in an error message when backing up the client. (You can ignore the error message.) If backups of the RSM database are generating errors, or causing the job to fail, you can disable backups of the RSM database by creating the filter {RSM} in the subclient that backs up the System State.
After performing a Full iDataAgent Restore, you will be warned that some system files have been replaced by unrecognizable versions. Select Cancel to accept these restored files.
To work around this issue, correct the attributes of the mount point, after it is restored.
Mount points to free space are assigned with Disk GUIDs. If a condition occurs that changes the disk GUID, the mount point will not restore correctly. For example, if the restore is to different hardware, or the existing hardware has been repartitioned with a tool that reassigns disk GUIDs (such as diskpart). This issue does not affect Mount points to drives or folders. To work around this issue:
If, after multiple attempts for index-free restores, the progress indicator completes with less than 100%, the restore completes with one or more errors, and the statistics are incorrect, all files are restored with no errors. Checking the list of restored files can verify the restore.
Despite the error message, all files are restored with no errors. Checking the list of restored files can verify the restore.
Mount points created to the out-of-place restore location should be removed using disk management tool.
Files backed up with data encryption will inherit the ACLs of the folder to which they are restored.
Files are restored with the icon that indicates a link, even when they are not links. The files are successfully restored, only the icon is incorrect.
Back up the system state with VSS (for Windows iDataAgents that support VSS) or restore the logs after Media Explorer restore with a restore system database operation.
Use the Restore System Database feature of the iDataAgent to restore the disk quota database.
After a full iDataAgent restore, this folder is restored as a visible folder although it was hidden by default.
Full system backups of a created ADAM instance cannot be restored using full system restore.
There is no workaround for this limitation.
Review the following Release Notes for additional issues that may be relevant to this Agent:
For clients running Windows Server 2003, you must supply a domain account rather than a local account for any user impersonation procedures.