Experienced little things-3, or “Central File Storage”

We continue the series of posts on "experimental little things." The previous parts can be read here: one , two .

Today I will tell you how I built a more or less harmonious system of internal file storage for the company and what came of it.

Let me remind you, for those who forgot that in my case we are talking about small companies, 30-500 people, and this leaves a certain imprint on the decisions made.

So, the task was set to somehow organize all the network file resources that were in the company. For convenience, for the system, for accounting, for reliability (underline as necessary).

I will not bore with a long description of searches and throwings, I will tell you what was born at the end, and what advantages came of it.

File storage scheme

Immediately abandoned the scheme \\ servername \ sharename. In the AD domain, they raised the domain DFS root, which itself lies on several servers, for greater fault tolerance (2-3, if the site is one, then it is no longer necessary, it will be worse).
At the root of the DFS links of the system was built as in the picture: . The purpose of the folders is as follows:

• Bases - here various databases are stored with which the company works, and this may not be 1C or similar databases, but also file databases, for example, an archive of photos of goods sold by the company, an archive of video tutorials, etc. Access to these folders is granted solely on the basis of groups in AD. In general, access to the folder (even if one person needs it) is best done on the basis of a group, not a specific user. Further it will be easier to manage.
• Common - here are the folders to which access is assigned ambiguously. For example, employees from different departments should have a common folder for work (financiers and accountants, sales, warehouse and transport workers, etc.). Access to these folders is again assigned based on groups in AD
• Users - here are the user folders, for example, the redirected My Documents and Desktops. Access only to a specific employee.
• Departments - everything is clear here. There is a department - he has a folder for internal documents. Access only to employees of the department who are part of the group of this department
• Public - a folder common to all. Access is allowed to all. Once a day \ week is cleared. For better safety, you can backup before cleaning (with our WinRar script, we drove all the contents into the archive with removal from the source)

Beauty guidance

Then, when we decided on the structure, a number of “file cuts” were made:

• because the domain was of 2003 level (and DFS, respectively, too), then we downloaded and installed Access-based Enumeration on all the servers that stored our data, which allowed us to hide from our employees those folders that they don’t have access to, so that our eyes would not be too callous.
• All level 1 folders (except users) were made virtual, i.e. the real balls were level 2 folders . This allowed a fairly flexible load balancing between servers. For example, 1C Databases could lie on one server, and the media archive on another, while the path for the end user remained the same.
• For the Users folder, they made special rights (they left Creator owner rights for the subfolders, and Domain users allowed only to create folders inside Users and that's it.) And wrote a short script that, when a user logs in, checks for the presence of HIS folder on the path \\ domain \ root \ users \ and if I didn’t find it, then created it there, calling by username. After that, desktops and documents were redirected to this folder by the policy, and if the redirection was not required (there were such), then simply map it as a network drive. As a result, the user automatically had his storage location, where no one else could get, and where he could store his data.
• With rights, they generally did this: they removed everything from the ACL, except for Domain Admins , Adm_FileStorage , Dep_Topmanagers , System plus additionally created groups (for example, Dep_Finance , Dep_Sklad or Com_Reklama_RW , etc.). In some situations, I still had to tinker a little, for example, in the Common \ INFO folder, I expressed a desire to have a number of departments with my directories, and accordingly they were given RW access there, and everyone else had only read
• quotas were introduced for the amount of data inside Users . tried to play with FileScreening (prohibition of data storage by type, for example, you can’t put * .mp3 in the folder), but it didn’t take root, because there was no particular need.
• The folder names used the Latin alphabet without spaces (this will simplify life in the future, even though scripts should be written to send links to files at least), groups in AD tried to create relatively "speaking" ones, so that at least it would be possible to understand why this group was needed.
• The balls themselves were made with $ at the end, and access to users on the network (network drives, settings paths in programs, etc.) was assigned exclusively through DFS paths

As a result, the system became more or less structured, it was possible to figure out where what lies, how to backup it all, where is its area of ​​responsibility, and in part numerous duplicates even disappeared when users were finally told what to store. In addition, it was possible not to worry about the breakdown of any server, the data was recovered from backups, but the structure remained, it was enough to fix the links to the new server in the DFS console.

To be continued .