Experienced trivia-3, or "Central Storage"

We continue the cycle of posts about "experienced trifles." Previous parts can be read here: one , two .

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

Let me remind you that for those who have forgotten 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 streamline all network file resources that were in the company. For convenience, for the system, for accounting, for reliability (underline the necessary).
')
I will not bore you with a long description of searches and throwings, I will tell you what was born at the end, and what advantages this came out of.

File storage scheme

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

• Bases - various databases with which they work in the company are stored here, and this may not necessarily be 1C or similar databases, but file databases, for example, an archive of photos of goods that a company sells, an archive of video lessons, etc. Access to these folders is distributed solely on the basis of groups in AD. In general, access to a folder (even if it is needed by one person) is best done on the basis of a group, and not a specific user. Further it will be easier to manage.
• Common - here there are folders, access to which 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 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. There is a department - it has a folder for internal documents. Access only to department employees who are in the group of this department.
• Public - a common folder for all. Access is granted to all. Once a day \ week cleared. For greater safety, you can make a backup before cleaning (in our case, WinRar drove all the contents to the archive with removal from the source location)

Beauty Guidance

Then, when we decided on the structure, a series of “file doping” was made:

• because the domain was at the 2003 level (and DFS, respectively, too), then to all the servers that stored our data, they downloaded and installed Access-based Enumeration , which allowed them to hide from the employees those folders that they did not have access to, so that they didn’t call the eyes.
• All level 1 folders (except users) were made virtual, i.e. real balls were folders 2 levels . This allowed quite flexible distribution of load across servers. For example, 1C Bases could be on one server, and the media archive could be 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 subfolders, and Domain users were allowed to create folders inside Users and that's it.) And wrote a short script that, when the user logged in, checked for the presence of HIS folders along the path \ \ domain \ root \ users \ and if I did not find it, I created it there, calling it by user name. After that, desktops and documents were redirected to this folder by the policy, and if redirection was not required (there were such), then simply map it as a network drive. As a result, the user automatically had his storage place where no one else could go, and where he could store his data.
• With the rights in general, they did this: they removed everything from the ACL, except for Domain Admins , Adm_FileStorage , Dep_Topmanagers , System plus additional groups created (for example, Dep_Finance , Dep_Sklad or there Com_Reklama_RW , etc.). In some situations, I still had to tinker a little, for example, in the Common \ INFO folder, a number of departments wanted to have their own directories, and accordingly they were given RW access, and everyone else was only reading
• quotas were entered on the amount of data within Users . tried to play with FileScreening (prohibition of storing data by type, for example, you cannot put * .mp3 in the folder), but did not stick, because there was no particular need.
• The names of the folders used the Latin alphabet and without spaces (this will simplify life in the future, even though the scripts write at least send links to files), the groups in AD tried to create relatively "speakers" so that at least you can understand why this group is needed.
• The balls themselves were made with $ at the end, and access to users to the network (network drives, settings paths in programs, etc.) was assigned exclusively via DFS paths.

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

To be continued.