Continuation of “experimental trivia”. You can read the previous parts.
Today's release will be a promise release. Fulfilling what I promised, I will tell you how you can do an interesting thing using DFS. This will, of course, not be full-fledged fault tolerance for file data, but something similar to an online backup, at a minimum.
To begin with, I will repeat my empirical beliefs that you should not arrange file cluster, by means of DFS. DFS was not created for these purposes. And to dot the I's, here are my arguments:
- In the DFS mechanism, there is no way to determine which replica of a file is correct.
- If there are several replicas in one site, DFS itself chooses where to send the user request, to replica A or to replica B, focusing, apparently, on the load on the storage server. (There are some settings for the order of replica selection, but they do not change the essence: if there are several replicas within a site, then the choice of a particular one can be unpredictable.
- These nuances allow us to simulate a situation where user A accesses replica A and works with data there, and user B accesses replica B and works with data there. As a result, TWO branches of changed data will be formed, and DFS will not know which data is correct, but will simply select those with the most recent changes. Can you imagine what will happen in this situation with file storage, or worse, with databases
- Well, it’s worth noting that replication of open files may be delayed indefinitely. The simplest example is users who do not close office documents leaving home.
You can build a kind of online replica based on DFS, which will not work most of the time (which means most of the problems with data synchronization will not appear), and which can be turned on if the main replica fails.
For example, it might look like this:
Here (using the Department folder as an example), two replicas of one folder have been created, a replication group and replication tasks have been configured (all this is done by the configuration wizard and will not cause you any problems). The best idea is that one of the links to the storage server is disabled, i.e. there is a replica, replication between servers proceeds as specified, but users accessing this folder via DFS will be redirected exclusively to the first, active server.
The second server will replicate data as much as possible, and will be, as it were, “on the hook”. In case of some emergency situation, it will be possible to cast and turn on the link already to the second server, and turn off the link to the first one, and users will again get to their native data, which will be as up-to-date as DFS replication was able to do (in practice, this is from complete relevance, i. i.e. states 0.5-2 seconds old, up to 2-3 days in the case of open files that are not replicated until they are closed, i.e. unlocked by the application).
It would seem great! Let's urgently run to make this super system! But besides all the good points, there are also not so good ones:
- A minimum of two times the space on each volume will be required for hidden folder DfsrPrivate( service folder for data replication). Given the double cost of data storage (both servers store the same thing, and at the same time they work with only one), this does not look so tempting anymore, because. space for such fault tolerance must be allocated at least 4 times more than the data itself
- Users may sometimes experience slowdowns when working with DFS. I didn’t manage to understand the exact reasons, but this was always the result of the presence of several replicas, and a non-zero load on the network. As soon as there was only one replica left, the brakes became vanishingly small. This was definitely not related to working replication, it looked very much like some kind of problem with resolving DFS names.
- In order for users to see the new replica that you switched them to at "hour X", they will most likely have to reboot their computers, otherwise they will try to follow the old path.
- I didn’t do automatic switching to a working replica, because... standard methods not for this, but writing a miracle script in a situation where the technology itself has so many disadvantages seemed to me recklessness.
By the way, according to those who know, among Windows Server 2008 (R2) DFS (and especially its replication service) has been dramatically improved and may have successfully addressed some of the issues. Try it - maybe the proposed scheme will work much better there.
To be continued.
Q why do you need DFS?
A to organize a single structured fault-tolerant file storage space in the organization. instead of a zoo of incomprehensible balls and disks, we have a single root (which can be mapped to users as a disk, for example), in which we can create a structure convenient for us in the form of virtual folders (either nested or mixed with real ones), to which, in a form convenient for us, we hook network balls physically located on different servers. people, people, one network drive- this is a pipets how convenient compared to the collective farm, which the majority have!
Q whether to integrate the namespace into Active Directory(Domain Based DFS Namespace) or standalone (stand-alone DFS namespace)?
A the integrated DFS namespace is stored in AD (backed up, accordingly, “for the company”. You do it backups Active Directory? ;) and allows you to have multiple namespace servers, ie. has a built-in fault tolerance mechanism. Stand Alone DFS NS does not have built-in mechanisms (fault tolerance is achieved through the use of clustering). Microsoft recommends using domain based DSF if the number of links (virtual folders) is no more than 5,000. Stand Alone DFS recommends a limit of 50,000 links. This is not a strict limitation, these are recommendations (after exceeding the figure, it seems that productivity should begin to decline). those. As a result, we find that stand alone is beneficial to use in a small network, for example, if there is no AD or, conversely, in the case of an extremely large file dump; in other cases, it is more profitable to use the integrated DFS namespace.
PS: some more irresponsible bourgeois write "Standalone DFS root do not have any DFS shared folders in the root level and only one level of DFS link is possible", but I don't quite understand what that means.
Q What are the fault tolerance mechanisms in domain based DFS?
A DFS root information is stored in Active Directory (in case you have several domain controllers, the reservation is obtained here too) and replicated to DFS namespace servers (of which there can also be many). links (virtual folders that you create in DFS Root and to which you mount physical balls) can have several (not necessarily 2, you can have more) ball sources, the data in which is replicated among themselves.
Q what is DFS replication and what types does it exist?
A mechanism for synchronizing content across multiple DFS sources.
It happens: FRS(File Replication Service) - regular replication;)
DFSR(Distributed File System Replication) - a fashionable replication that appeared in Windows Server 2003R2 and 2008. uses RDC (differential compression, i.e. only changes in the file are transmitted, and not the entire file that has changed, as it was in FRS. in general, for our dead channels it is very useful stuff). I note that DFS replication is asynchronous, i.e. For some time the sources are not consistent.
Q What to pay attention to after deploying DFS
A on the location and security of the DFSRPrivate folder in each source (used to store replicated information, deleted and conflicting files in terms of replication). by default, it is stored in the source folder itself with rights inherited "from above" (generally strange, it is written on technet that only administrators will have access. maybe something was corrected in 2008R2). if you have rights within the source folder security is different (which in itself is somewhat clumsy from the point of view of the file cleaning architecture), then people can get access where they don’t need it, plus, the playful little hands of Kulibins will not add joy.
Q What is the folder "DFSRPrivate\Staging" and how to choose its size correctly?
A this is the folder where temporary copies of files are stored for replication, through which they are essentially transferred. available in all sources. size, at least for the time of primary replication, it is better to set a little more than the size of the maximum occurring file in the replicated folder (unless you have extreme games that store warez gigas in one terabyte archive, of course). important: a file larger than the Staging folder is normally replicated and will not get stuck anywhere, as some people think, the replication process will simply go through several stages (the file will be cut into several parts and transferred in parts), which will slow down the process somewhat.
Q what is the folder "DFSRPrivate\Conflict and Deleted"
A since several users can change the same file at the same time, the principle "who last wrote the file, that and slippers" works. the failed file is sent to this folder, and a corresponding entry will appear in ConflictandDeletedManifest.xml. also, if there is a checkbox "save" deleted files in the conflict folder" files deleted by users will be stored there (very convenient to restore). so I would not skimp on the size.
Q What are the main problems with DFS replication?
A Most of my problems with DFS replication arose due to File Screening (restriction on allowed file extensions) and Disk Quotas (restriction on folder size). especially in the case of primary replication. everything is clear with disk quotas, you need to follow them (given that the DFSRPrivate directory, along with "Staging" and "Conflict and Deleted" is located in the source folder itself by default), then with File Screening it's a complete mess - you need to either move the DFSRPrivate folder to a place, where there are no restrictions (which is not convenient) or try to make exceptions for the "DFSRprivate" folders (and it is hidden. gygy) or temporarily disable restrictions (in the primary source too! otherwise the file will not get into Staging on the source and will not be replicated) or delete all files users that fall under the prohibition filters (let me remind you that the screening file only prohibits the creation of new files of certain extensions, and not their presence. i.e. if the files already exist and we include prohibition rules in screening, then files that fall under the filters cannot be created -change, but you can read-delete. here we get an error when trying to replicate, when the service tries to write a forbidden replicated file to the Staging folder, file screening will swear with the "no disk space" error, on which all replication will stop).
Q where are detailed replication logs stored?
A except eventlog"a in %windir%\debug\DFSR*.log.gz - archived, and %windir%\debug\DFSR*.log - current.
Q What are the subtleties in the work of DFS?
A1 although it is possible to mount one namespace as a folder in another namespace, in practice, when mounting stand alone DFS Windows Server 2003 to the folder of another AD DFS-integrated Windows Server 2008, this avant-garde led to a BSOD "when entering such a folder with company with Windows XP ;) apparently, the bourgeois had in mind that you can splice only different domain based DFS namespaces.
A2 when the primary folder in DFS drops out, when accessing it from Windows XP there is a delay equal to the caching time of the DFS structure (300 seconds by default, as far as I remember). If you log in with Windows Vista/7/2008, there is no delay. as the bourgeoisie write, it’s due to the rewrites in the new windows network protocols. so a full-fledged auto failover, if you have XP clients, will not work; you need to use slightly different means or turn off the sources manually (for example, in case of a planned shutdown of one of the servers).
A3 Since replication in DFS is asynchronous, you should not keep any databases in a folder with two or more replicated sources. at the moment of transition between sources it becomes desynchronized.
Q What else could you do with DFS?
A enable ABE (Access Based Enumeration) in the properties of each share - this technology allows you to hide from the user folders to which he does not have access. useful for many reasons - and we don’t annoy the user with a bunch of folders that he won’t be able to go into (he will only see those folders to which he has access), and we don’t give out any indirect information (few people won’t be alarmed by the folder " Plan to reduce staff by three times") and makes navigating the file dump more convenient.
Q How do I even log into DFS after creation? ;)
A in the case of Doman Based DFS Namespace - "\\DomainName\DFSRootName" in address bar Explorer"a, in the case of Stand Alone - as in a regular share - "\\ServerName\DFSRootName". You can map like a regular share - " net use Z: \\DOMAIN.Local\MyCoolDFS\" and "net use Z: \\Server\MyCoolDFS\" respectively.
Distributed File System DFS(Distributed File System) is a technology that provides opportunities to simplify access to shared file resources and global data replication. Thanks to DFS, shared resources (directories and files) distributed across various servers can be combined into a single logical UNC structure, which to the user looks like a single network resource. Even if the physical location of the target folder changes, it does not affect user access to it.
The implementation of DFS services in Windows Server 2012 is different from previous versions Windows. First of all, we note that DFS technologies in Windows Server 2012 are implemented in the form of two separate services independent of each other - DFS Namespaces And DFS Replication included in the file server role (File and Storage Services).
- DFS Namespaces (DFSN or DFS-N)– DFS namespace. Allows you to combine into a single logical structure shared folders, located on various servers of the organization. Each namespace appears to the user as a single network folder with subdirectories. The actual structure of a given DFS namespace is hidden from the user, and may include various network folders located on different servers and sites.
- DFS Replication (DFSR or DFS-R)— DFS replication service. Allows you to organize an effective replication service for directories (including those included in the DFS namespace) between different servers and AD sites. For replication, this service uses a special remote differential compression algorithm - RDC-remote differential compression. Thanks to RDC, which tracks changes in files, replication does not copy entire files (as is the case with FRS replication), but only their block changes.
Installing DFS Services on Windows Server 2012
You can install DFS services using the Server Manager console or by Windows Help PowerShell.
As we said, DFS services are role members Files and Storage Services:
But it’s easier and faster to install all DFS services and the DFS management console using PowerShell:
Install-WindowsFeature FS-DFS-Namespace, FS-DFS-Replication, RSAT-DFS-Mgmt-Con
Advice. Naturally, services and the DFS management console can be installed separately.
Where FS-DFS-Namespace– DFS Namespaces service
FS-DFS-Replication– service DFS replication Replication
Configuring a DFS namespace in Windows Server 2012
Let's move on to a description of the procedure for setting up the DFS namespace, for which you need to open the control panel DFS Management tool.
Let's create a new namespace ( New Namespace).
You must specify the name of the server that will contain the namespace (this can be either a domain controller or a member server).
Then you should specify the name of the DFS namespace to be created and go to the advanced settings (Edit Settings).
Here you must specify the name of the DFS namespace and permissions to this catalog. It is generally recommended to indicate that access to network folder allowed to Everyone, in this case access rights are checked at the NTFS file system level.
Next, the wizard will prompt you to specify the type of namespace to be created. It could be Domain-based namespace(domain namespace) or Stand-alone namespace(separate namespace). Domain-based namespace has a number of advantages, but for it to work you need the Active Directory domain itself and domain administrator rights (or the presence of delegated rights to create DFS domain namespaces).
After the wizard completes, the new DFS namespace we created will appear in the Namespaces branch of the DFS management console. To ensure that when users access DFS directories, they see only those directories to which they have access, we will enable DFSAccess-Based Enumeration for this space (more about this technology in the article). To do this, open the properties window of the created namespace.
And on the tab Advanced enable the option Enable access-based enumeration for this namespace.
To view the contents of the new DFS space, simply type the path in the UNC Explorer window: \\domain_or_server_name\DFS
Adding an additional DFS server
You can add an additional server to the DFS domain namespace (menu item Add Namespace Server) that will support it. This is done to increase the availability of the DFS namespace and allows the namespace server to be located in the same site as the users.
Note. Stand-alone DFS namespaces support only one server.
Adding a new directory to an existing DFS namespace
Now we need to add a new network directory to the hierarchy of the DFS namespace we created. Click the button Add Folder Target.
Specify the name of the directory in the DFS space and its actual location on the existing file server ( Folder targets).
Setting up DFS replication on Windows Server 2012
Technology DFS-R replication designed to organize fault tolerance of the DFS namespace and load balancing between servers. DFS-R automatically balances traffic between replicas depending on their load and, if one of the servers is unavailable, redirects clients to another replica server. But before we talk about DFS replication and its configuration in Windows Server 2012, we list the main system requirements and restrictions:
- DFS Replication must be installed on all servers that will be included in the replication group
- All servers in a replication group must be in the same AD forest
- The Active Directory forest level must be at least Windows Server 2003 R2 (if installing your first domain controller on Windows Server 2012).
- Domain functional level - at least Windows Server 2008
- You need to make sure that antivirus software on file servers compatible with DFS replication technology
- Replicated directories must be located on volumes with file NTFS system(file systems and FAT are not supported). Replication of data stored on on Cluster Shared Volumes is also not supported
In the DFS Managment console, select the DFS Namespace you need and right-click on the directory for which you want to create a replica and select Add Folder Target.
And specify the full (UNC) path to the network directory of another server in which the replica will be stored. 
When asked if you want to create a replication group, answer Yes. 
The Replication Configuration Wizard starts. We check the replication group name and directory. 
We indicate the primary ( Primary) server. It is this server that will be the data source during initial (primary) replication. 
Then we select the type of topology (connection) between the members of the replication group. In our example we choose Full Mesh(all with all). 
And finally, we specify the replication schedule and bandwidth throttling parameters - limiting the bandwidth available for replication. 
After the wizard finishes, the initial synchronization will start.
If necessary, configure advanced replication schedule parameters and maximum bandwidth under this traffic, can be set in the branch Replication.
Microsoft Dfs provides an excellent opportunity to provide users with easy access to data stored on remote computers. With Dfs, you can browse and access folders as a separate set of shared directories through a familiar, unified hierarchy, even when the resources are located on different domains or physical media. For those who do not use the Dfs service, fearing its complexity, I want to rejoice: there is nothing to be afraid of - setting up Dfs is intuitive, and using it is even less difficult. In this article I will explain how this service works and introduce readers to typical setup. Once administrators start using the Dfs service, they usually no longer understand how users managed without it before.
How Dfs works
The main element of the structure of this service is general directory, which represents the root of the Dfs hierarchy. With the help of Dfs these network directories form a consistent separate namespace. Client systems use familiar concepts such as mapped drive or UNC (Universal Naming Convention) path to connect to the Dfs root. Once a client is connected, the Dfs structure acts as a normal shared directory containing subdirectories that users can navigate through. Each subdirectory accessible from the Dfs root is actually a link to a shared directory (the source of the link) anywhere on the network. Dfs automatically directs a client that accesses a network share to the real location of the data. As Figure 1 shows, the folders that the user sees are Dfs redirects for users to different shared directories on servers A, B, and C. The link source can be any system that uses a network file system, which can be accessed via a UNC path, such as Windows, Novell NetWare and UNIX systems, or Linux (that is, machines with the NFS file system).
Rice. 1. Dfs data redirection
The Dfs service allows you to use two types of roots: standalone and integrated into Active Directory (AD). They differ in the way they store Dfs data. In the case of standalone roots, the Dfs hierarchy, consisting of various network directory links, is stored in the Dfs server's local registry. This method of storing information does not imply the possibility of duplicating it on other Dfs servers, that is, if the only Dfs server containing the Dfs root becomes unavailable, the Dfs hierarchy is completely inaccessible to all clients on the network. If the Dfs server is unavailable, clients can still access shared directories on the servers directly. They just won't be able to use the Dfs service to access resources. You will have to use standalone Dfs roots if the system does not contain AD or if the Dfs system administrators are not domain administrators and therefore cannot gain sufficient rights (that is, access the DFS-Configuration object in the container System section AD for domain) to manage the Dfs system.
Windows 2000 Server and later also support AD-integrated Dfs roots (also known as domain Dfs roots or fault-tolerant Dfs roots). When using integrated roots, Dfs information is stored primarily in AD, although live Dfs servers also maintain copies of the data in memory to minimize the number of times the Dfs server contacts domain controllers (DCs) and thus reduce the network load from the Dfs service. AD-integrated roots can only be used when the Dfs server is a member of a domain. However, the Dfs server does not have to be a domain controller. Essentially, you should use standalone Dfs roots if you don't have an AD domain, need to host more than 5,000 links, or if your network contains legacy client systems. More detailed information For information on the differences between standalone and AD-integrated Dfs roots, see the “So Different Roots” sidebar.
Once you decide what type of Dfs roots you will use, you need to configure the links and link sources that contain the data that Dfs will provide to clients. As already mentioned, the source of the link is shared resource, to which Dfs directs the client when accessing the link. A link can have multiple origins, which provides load balancing and fault tolerance: if the shared directory on one of the servers is unavailable, Dfs directs the client to another copy of the data. The existing link source used by the client depends mainly on the location of the client. Essentially, Dfs is a service for establishing a relationship between hosts on a network, that is, by default, if the source of the link is close to the client, then Dfs directs the client to this source links.
Setting up Dfs
Now that we have studied the most important concepts Dfs system, you can start setting it up. The first task is to create a Dfs root. There are two ways to do this: using Microsoft Management Console (MMC) of the Distributed File System snap-in and launching the dfsutil.exe application from command line. In this article, we'll look at snap-ins that are slightly easier for beginners than dfsutil.exe. Once you've become familiar with Dfs, you might want to use dfsutil.exe, for example, in a script that populates the Dfs hierarchy with links. Then you need to keep in mind that on Windows Server 2003 systems, Standard Edition and Windows 2000 Server server can only contain one Dfs root. Windows Servers Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition can work with an unlimited number of Dfs roots.
To create a new Dfs root using the Distributed File System snap-in, you must complete the following steps:
Launch the Distributed File System snap-in (the item is located in the Administrative Tools folder of the Start menu).
Click right click mouse over the Distributed File System heading at the root of the tree in the panel and select New Root (if you are using Windows 2003) or New DFS root (for Windows 2000 Server). The following steps use dialog boxes Windows 2003 systems, although the process itself almost completely repeats the process for the Windows 2000 Server shell.
In the welcome window, click the button Next.
Select the type of root to create (domain or standalone). Click Next.
If you select Dfs Domain Root, you will need to enter the name of the domain that will store the Dfs service information. If you select an offline root, you must enter the name of the server that will store the relevant information. Click Next.
If you selected a domain root in step 4, the program will ask you to select a server that will contain the Dfs root. You should specify the server and click the button Next.
Enter the name of the new root and any comments that will help identify it, then click Next. Once you enter the root name, you'll see what the name would look like as a UNC share name, as Figure 2 shows. For example, for a domain share Dfs name The path has the structure domain name\directory name. If on this moment the shared directory does not exist, you need to select local folder on the system as a shared directory. This directory contains no real data; instead it includes reference objects pointing to physical location data. You must select a folder to use as a shared directory and click Next.
In the confirmation window, click the button Finish.
Rice. 2. Specifying a new Dfs root
At this point, clients can connect to the Dfs namespace using the UNC path \\dfstest.test\shared. They don't need to know anything about which servers contain Dfs elements. Clients running Windows NT 4.0+Service Pack 6a (SP6a) or later can connect to the Dfs domain namespace. Clients using Windows shell 98, can access stand-alone Dfs namespaces, but must have installed extension, AD service client, to connect to the domain namespace. Wednesday Microsoft downloads Windows Preinstallation Environment (WinPE) can only access standalone Dfs namespaces.
To take advantage of the resiliency of the Dfs domain namespace, you need at least two Dfs servers supporting the same namespace. To set up a second Dfs host server, follow the instructions below:
In the Distributed File System snap-in, right-click on the created root and select New Root Target.
Enter the name of the server that will serve as an additional Dfs host for the namespace. Keep in mind that the name of the shared directory (eg shared) that Dfs will use to contain this copy is already set and cannot be changed. Click Next.
If a directory with the same name does not exist on the specified server, the system will prompt you to select a folder to use as this, or you can create a new folder and then select it. Select a folder and click Next.
In the resulting window, click the Finish button.
The Dfs root will now display multiple servers that act as the namespace's root objects, as Figure 3 shows. Clients can connect to the namespace and be directed to one of its root objects. However, users accessing the root object will only see an empty folder because no links have been set yet. Next step there will be the addition of multiple links and link sources that will direct customers to the data they need.
Rice. 3. View Dfs root sources
At this stage, in order to complete setting up the Dfs system, it is necessary to create a list of shared directories in the company, detect and take into account duplication of data in various directories and decide in what form we will provide the data to clients (that is, select the folder name and comment text). Once all the above information has been collected, you can create links by following these steps:
Right click on the Dfs root and select New Link from context menu.
Enter the name of the link (that is, the name of the folder that the client will see) and the name of the shared directory that the link will direct the client to. This name can be changed or added later. You can also enter a comment and define the period of time that clients will store source information before contacting the Dfs server again, as Figure 4 shows.
Click the button OK.
Now when clients get into the Dfs namespace they will see the folder. When opening this folder, the user will be redirected to the shared directory and will be able to view its contents.
Features of the DFS service
1 This component allows you to create a namespace that is essentially free of shared folders based on different servers, that is, all network users can use shared files and folders, regardless of their location.
2 The ability to set up a replication service that synchronizes folders and files across the organization, giving users access to the latest and most up-to-date versions of files (without having to worry about which server they are actually stored on).
In this article I want to describe step by step setup The first function is DFS Namespace, o. So, I will implement everything on operating system Windows Server 2008 R2, at the disposal of 2 servers - AD.test.ru - domain controller and SERV1.test.ru - server on which the DFS role will be installed.
Attention!!!In order to take full advantage of the new DFS on Windows Server 2008 R2, you must meet a number of requirements: all servers participating in DFS must be at least Windows Server 2008, and the AD domain level must be at least Windows 2008.
So, the first thing you need to start with is install role DFS Namespace, for this, on the server (in this article it will be the SERV1. test.ru server), click on the shortcut "Server Manager - Roles - Add Role".
The next window will be informational, read and click "Further". Then select the required role, in in this case we are interested in the role File Services.
After that it will appear information window, read and click "Further". Then select role services DFS namespace And DFS Replication(this article will not describe the configuration of this service, I will focus on it in the next article). 
I suggest setting up the namespace later, for this we select "Create namespace later..." and press "Further".
We complete the installation - click in the confirmation window "Install" and after successful installation click "Close".
Half the job is done, all that remains is to configure the DFS namespace; to do this, open the DFS console. To do this, press "Start- Administration-Management DFS".
A window will open "DFS Management", to create DFS click on "Namespace - New Namespace".
The first thing to do is to specify where the namespace will be located, in in this example I will use the AD.test.ru domain controller. 
Next we indicate the name of the namespace, in this example "Total" and press "Next".
In the window "type namespace" to increase fault tolerance, I recommend choosing "Domain namespace".
After this, a window will open with all the settings made; if you are sure of the settings, click "Create" and after a few minutes the DFS namespace will be created. After this, you need to create namespace folders; to do this, you need to share the folders (open network access to folders) that will be connected to DFS. In this example, I shared two folders (I did this on two different servers to make the DFS capabilities clearer) Folder1 and Folder2. Then click "Create a folder".
We specify the name (this name will be displayed in the DFS namespace and may differ from the name of the connected folder) and indicate the path to the folder. 
And so, we created a folder Folder1 in DFS. 
In a similar way, add another folder. As a result, we have two folders added to the namespace, which are physically located on different servers. 
Now, if we go to the path \\test.ru\Total (this link applies only to this concrete example, in your case, you indicate the data that you specified during setup), we will see the created shortcuts. 
For ease of use of the namespace, I recommend connecting a network drive indicating the path to DFS. To do this, open on the user’s computer "Computer", select from the top of the panel "Map network drive" and in the settings we specify the path to DFS, in this example \\test.ru\Total. 
As a result, for end users It will be very convenient to see one network drive, by logging into which they will see all the folders they need without thinking about where this network resource is stored.
