In a Windows server or Active Directory domain, a unique value called a Security Identifier (SID) is associated with a user name. When a user creates a file, the default owner is normally the SID for the user that creates the file. If the user is a member of the Administrators group or the Domain Admins group, the default owner is the SID for the group, not the SID for the individual user account. If a user’s user name is deleted from the server or Active Directory, the user name becomes invalid. The user’s files contain the user’s SID, but the SID is no longer associated with a valid user name. This document refers to those files as orphan files, or ownerless files.
To move orphan files between paths in a pair, you can use any policy rule, including File Owners. Dynamic File Services adds a {No owners} user that you can select when you set up a File Owners policy. In a policy with a File Owner rule, the policy engine checks that the users and groups in the policy are valid each time the policy runs. It also checks the current membership of the valid groups. The File Owner policy normally moves only those files associated with valid user names, valid group names, and current members of valid groups. It can also move ownerless files if you select the user {No owner} for the policy.
The manual move process moves any file that you specify in the list of files to be moved. The owner is not a consideration in whether the file is moved.
For retention pairs, Dynamic File Services keeps a UserName-SID database (DswUserDB.xml) that contains information about the user names or group names associated with the file owners’ SIDs. The file is located in the C:\Program Files\Dynamic File Services\ directory, or in the custom install location.
As a file is moved to a retention repository, an entry is added to the UserName-SID database if the name is valid. For example, the following is an entry for a local Administrators group’s SID in the DswUserDB.xml file:
<TrackerEntry> <SID>S-1-5-32-544</SID> <Name>Administrators</Name> <IsValid>true</IsValid> </TrackerEntry>
An entry is kept until there are no more files with the SID in any repositories of the retention pairs on the server. Because the user name is known to Dynamic File Services, the user’s files do not become orphaned in the repository if the user name is deleted from the server or from Active Directory, even though the files might be orphaned from the file system point of view.
The user names and group names in the database are validated daily (at 0030 hours by default) against the users and groups for the server and for the Active Directory domain (if present). The name’s validity status is set to if a name becomes invalid. If an invalid user name becomes valid again (such as through an Active Directory restore action), the validity setting is set to when the database is next validated.
Dynamic File Services validates the user names and group names against the information stored in the Active Directory domain controller for the server. After you remove a user name or group name from Active Directory, the following must occur before Dynamic File Services is aware of the change:
Active Directory synchronizes the invalid status of the name with the domain controller for the Dynamic File Services server. When this update occurs depends on Active Directory.
Dynamic File Services runs the daily validation check for the Username-SID database on the server.
During a retention review, a reviewer sees the name as valid until the Username-SID database has been updated. The Retention Review Service displays a file owner’s name with a strikethrough if the name is marked as invalid in the Username-SID database. This allows you to sort files by file owners, even if user names become invalid.
If an orphan file is moved to the repository, a new entry for its SID cannot be created in the UserName-SID database file because the user name is unknown to the file system. The Retention Review Service displays the file owner as . However, if other files in any repository on the server were moved there when the user name was valid, an entry exists for that relationship in the database, and the Retention Review Service can display the file owner’s name with a strikethrough.
If you restore an orphan file to the primary location, the owner information is not known to the NTFS file system. Only the SID is known from the file’s metadata. If the restored orphan file is the last file with that SID in any of the pairs’ repositories, its SID information is also removed from the UserName-SID database. If you move the orphan file back to the repository, the user name is now unknown to the Retention Review Service.
When a SID is not found for any of the remaining files in any of the pairs’ retention repositories, the SID’s entry is removed from the UserName-SID database. The entry is removed whether the user name information is valid or invalid at that time.
In a Windows Workgroup, each individual server maintains its own list of user names. Each server assigns a unique Security Identifier to the user name. Even though a user is given the same user name on different servers, the user’s files show different SIDs as the file owner, depending on which server is hosting them. This is not an issue in an Active Directory domain, because a user’s user name and SID are the same for all servers in the same tree or forest.
When you use Dynamic File Services in a Windows Workgroup, a file owner’s user name is lost when a file is moved from one server (primary or secondary) to another server (secondary or primary) for any type of pair. The file owner is the SID that is associated with the user name on the server where the file was created, or where the file ownership was last set. The relocated file is considered ownerless on the destination server, because the system cannot find a matching user name for the SID. The original SID is stored with the file. If the file is moved back to its original server, such as through a policy run or a retention review restore, the file owner is known on that server, assuming that the user name is still valid.
Although SIDs are unique on a given server (or across all servers in the same domain or forest), it is remotely possible (if statistically unlikely) that two servers in a Workgroup might generate the same SID. In that case, the SID on the original server might match a SID for a user name on the destination server, but it is highly unlikely that the SID represents the same user name or user.