Novell Storage Manager 4.0.2 for Active Directory is a maintenance release that adds functionality and fixes several bugs. As with the initial release of Novell Storage Manager 4.0 for Active Directory, this release deprecates the use of SQLite databases for application data storage. The Microsoft SQL Server product family replaces the use of SQLite and is the only supported database. See chapter 3 of the Novell Storage Manager 4.0 for Active Directory Installation Guide for further details.
This build addresses the OpenSSL FREAK vulnerability. For more information, see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0204.
The policy associations are now exported when you export a policy. If you intend to import an exported policy, you will need to perform the Remove From Database Management Action and then perform a Manage Management Action for the objects to which the policy applies.
When you import a policy, the objects that were managed by the policy become unmanaged objects; hence, the need to re-manage the objects affected by the imported policy.
When an Event Monitor misses a heartbeat and the NSM Engine is in a time zone whose offset is plus GMT (e.g. GMT +1), the Event Monitor configuration no longer indicates that a warning is present with the affected Event Monitor.
In cases where a policy’s Owner Override object wasn't cataloged, it was possible to get a name translation error if the object was renamed or moved.
If the Windows Firewall service was stopped or disabled, the Installer would produce an error and prevent the installation. The installer now ignores exceptions when attempting to create the necessary Windows Firewall exception.
The Process Group Moves option was not being honored properly. Specifically, when the option was checked and a group was moved from one container to another, the event would be ignored by the NSM Engine for processing.
When a share of a managed path was renamed, the path validation would fail, because the paths were malformed. This affected both the NSM Engine and the NSM Agent.
When using the new DS object search capabilities, if a string to be searched for contained an XML entity, such as '&', an XML exception would be returned by the NSM Engine.
The defined maximum limit for XML RPC messages was too small for Cross-Empire Data Migration Identity Maps. The size has been increased to 1GB.
Vault and Groom rule descriptions were not properly written to the RuntimeConfig report.
When a delegated delete event was being processed and the managing policy was configured for Immediate Cleanup and Vault on Cleanup, it was possible for the delete event and its dependent CopyData event to be set in a pending state. This is because the managed path might have been deleted before the dependent CopyData event was completed.
Delegated groom or vault events could have returned an Error 14 when copying individual files that resulted from matching a Vault Files action.
In certain cases, subtree processing of container objects would cause the Event Monitor subsystems to continuously restart, resulting in no new events being sent to the NSM Engine.
If the SQLite database that you were migrating had data in the ds_objects and transactions tables but it had no data in policies, the migration would not complete.
Novell Storage Manager 4.0 for Active Directory exclusively uses DNS FQDNs for server names in all UNC paths set in and by NSM. This is a change from NSM 3.x and earlier, where NetBIOS names were used (although a configuration option to use DNS names existed in NSM 3.1.x). This is per Microsoft’s own recommendations, as Microsoft slowly attempts to phase out NetBIOS and WINS.
This problem manifests itself when Folder Redirection has already been in effect where the UNC path value for the home folder uses one form of the host name, and then the UNC path of the home folder attribute is modified to refer to the same actual location but with the host name in the other format (e.g. switching from NetBIOS to DNS FQDN). Alternatively, switching the UNC path from server and share, (e.g. \\server\\share\\path-remainder) regardless of the host name format that was used, to using a DFS name space (e.g. \\some-domain.com\dfs-name-space\link\path-remainder) where the DFS link being used resolves to the same location as the original UNC path will also cause the problem to manifest itself.
The root-cause for the problem is that the Folder Redirection code in Windows, prior to the hotfix, was not resolving the old and new UNC path values for the home folder to determine if they refer to the same location on disk. Unlike Novell Storage Manager, which makes this determination via its “path overlap detection” functionality, the Folder Redirection code makes a bad assumption that it can unconditionally delete the files on the “old” path after it copies them to the “new” path and thus, it ends up deleting files that should not have been deleted.
These Windows bugs, which can result in loss of data in the redirected folders or the entire redirected folder, are described in the following Microsoft KB articles:
“You are unable to update the target location of offline file shares in the Offline File client side cache without administrative permission in Windows Server 2008 R2 or in Windows 7.” http://support.microsoft.com/kb/977229
“After you apply a GPO to redirect a folder to a new network share, the redirected folder is empty on client computers that are running Windows Vista or Windows Server 2008.”http://support.microsoft.com/kb/977611
These KB articles specifically apply to users logging on through Windows Vista or Windows 7 computers, as well as users logging on interactively on Windows Server 2008 and Windows Server 2008 R2. Users on other operating systems might be affected as well, however.
Both of the KB articles above include links to hotfixes that help resolve these issues.
While this is not a NSM issue per se, NSM’s exclusive use of DNS FQDNs in UNC paths can exacerbate this problem, or introduce it into an environment that was previously exclusively using NetBIOS naming for servers and using folder redirection. If your environment uses folder redirection, we strongly recommend reading the KB articles above and applying any relevant hotfixes before managing storage with NSM. (In fact, we strongly recommend applying these hotfixes if you use folder redirection in your AD environment with the affected operating systems, even if you are not managing user storage with NSM. Microsoft’s continuing push to move away from NetBIOS and WINS may eventually introduce this issue into your environment with or without NSM installed.)