Как правильно установить и настроить файловый сервер на Windows Server

В качестве примера используется Windows Server 2012 R2 (2016, 2019). Инструкция разбита на несколько шагов и представляет из себя полный цикл настройки файлового хранилища для использования в малых и средних компаниях.

Шаг 1. Выбор оборудования и подготовка сервера

В качестве сервера, желательно, выбрать профессиональное оборудование. Системные требования для файлового сервера не высокие:

• Процессор может быть самый простой;
• Оперативная память также не сильно используется;
• Дисковая система — самый основной компонент. Ее объем зависит от специфики бизнеса. Примерная формула — не менее 15 Гб на пользователя и не менее 1 Тб на сервер. До 50 пользователей можно рассматривать диски SATA, после — SAS или SSD.

Например, для компании в 300 пользователей подойдет сервер с процессором Xeon E3, 8 Гб ОЗУ и 5 Тб дискового пространства на дисках SAS 10K.

Дополнительные требования

1. Для обеспечения сохранности информации при выходе из строя жесткого диска, необходим RAID-контроллер. Настройка последнего выполняется из специального встроенного программного обеспечения, которое запускается при загрузке сервера;
2. Сервер должен быть подключен к источнику бесперебойного питания;
3. Необходимо предусмотреть резервное копирование. Для этого нужен дисковый накопитель (внешний жесткий диск) или другой сервер.

Подробнее о выборе оборудования читайте статью Как выбрать сервер.

Шаг 2. Установка Windows и настройка системы

Установка системы

На этом шаге все стандартно, за исключением одного нюанса: разбивая во время установки Windows жесткий диск, стараемся выделить небольшую часть (70 — 120 Гб) для системы и все остальное под данные. Если выделить много дискового пространства для системного раздела, увеличится время его обслуживания и фрагментация, что негативно скажется на производительности и надежности системы в целом.

Настройка системы

1. Проверяем правильность настройки времени и часового пояса;
2. Задаем понятное имя для сервера и, при необходимости, вводим его в домен;
3. Если сервер не подключен напрямую к сети Интернет, стоит отключить брандмауэр;
4. Для удаленного администрирования, включаем удаленный рабочий стол;
5. Устанавливаем все обновления системы.

Шаг 3. Базовые настройки файлового сервера

Это стандартные действия, которые выполняются при настройке обычного файлового сервера.

Установка роли и вспомогательных компонентов

Как правило, данная роль устанавливается вместе с Windows. Остается только это проверить и доустановить компоненты, которые нужны для полноценной эксплуатации сервиса.

Открываем Диспетчер серверов. Он может быть запущен из панели быстрого запуска.

Нажимаем Управление — Добавить роли и компоненты.

В открывшемся окне оставляем Установка ролей и компонентов и нажимаем Далее.

В следующем окне выбираем нужный сервер (выбран по умолчанию, если работаем на сервере, а не через удаленную консоль) и нажимаем Далее.

Среди ролей находим Файловые службы и службы хранилища, раскрываем ее и проверяем, что установлены галочки напротив следующих компонентов:

• Службы хранения;
• Файловый сервер;

Если данные службы не установлены, выбираем их и нажимаем Далее.

В окне Выбор компонентов просто нажимаем Далее.

Откроется окно Подтверждение установки компонентов. Нажимаем Установить и после окончания процесса перезагружаем сервер.

Настройка шары (общей папки)

Создаем первую папку, которую хотим предоставить в общее использование. Затем кликаем по ней правой кнопкой мыши и нажимаем Свойства:

В открывшемся окне переходим на вкладку Доступ и нажимаем Расширенная настройка:

Ставим галочку Открыть общий доступ к этой папке и нажимаем кнопку Разрешения:

Предоставляем полный доступ всем пользователям:

* конечно же, мы не будем давать доступ всем пользователям, но для этого есть вкладка безопасность (см. ниже).

Нажимаем OK и еще раз OK.

Теперь переходим на вкладку Безопасность и нажимаем Дополнительно:

В открывшемся окне нажимаем Отключение наследования и Преобразовать унаследованные разрешения в явные разрешения этого объекта.

Выставляем необходимые права на папку, например:

Совет: старайтесь управлять правами на ресурсы только при помощи групп. Даже если доступ необходимо предоставить только одному человеку!

Теперь нажимаем OK два раза. Папка настроена для общего использования и в нашем примере доступна по сетевому пути \\fs1\Общая папка.

Шаг 4. Тюнинг файлового сервера или профессиональные советы

Данные настройки, по сути, представляют секреты того, как сделать файловый сервер лучше, надежнее и безопаснее. Применяя их, администраторы создают более правильную и профессиональную среду ИТ.

С самого начала стоит создавать общие папки в пространстве имен DFS. На это есть две основные причины:

1. При наличии или появлении нескольких файловых серверов пользователям будет удобнее находить общие папки в одном месте.
2. Администратор легко сможет создать отказоустойчивую систему при необходимости.

Теневые копии

Позволят вернуться к предыдущим версиям файлов. Это очень полезная функция позволит не только восстановить некорректно отредактированный документ, но и вернуть случайно удаленный файл или папку.

Как настроить и пользоваться данной возможностью, читайте подробнее в инструкции Как включить и настроить теневые копии.

Аудит

Аудит позволит вести протокол доступа к данным — понять, кто и когда удалил важные данные или внес в них изменения.

О том, как настроить данную возможность читайте статью Как включить аудит доступа к файлам Windows.

Анализатор соответствия рекомендациям

В диспетчер управления серверами Windows встроен инструмент для проверки конфигурации сервера — анализатор соответствия рекомендациям. Чтобы им воспользоваться переходим в диспетчере в Локальный сервер:

Находим раздел «Анализатор соответствия рекомендациям» и справа кликаем по ЗАДАЧИ — Начать проверку BPA:

Рассмотрим решения некоторых рекомендаций.

1. Для XXX должно быть задано рекомендованное значение.

Это набор однотипных рекомендаций, для выполнения которых нужно обратить внимание на описание и задать значение параметро, которое в нем указано. Например, для CachedOpenLimit в описании проблемы есть описание решения — «Задайте для CachedOpenLimit рекомендуемое значение 5». Чтобы это сделать, открываем Powershell от администратора и вводим команду:

Set-SmbServerConfiguration -CachedOpenLimit 5

* мы задаем параметру CachedOpenLimit значение 5, как это и рекомендовано анализатором.

На запрос, уверены ли мы, что хотим выполнить команду, отвечаем утвердительно.

Остальные параметры задаем аналогичными действиями.

2. Файл Srv.sys должен быть настроен на запуск по требованию.

В командной строке от имени администратора вводим:

sc config srv start= demand

3. Создание коротких имен файлов должно быть отключено.

В командной строке от имени администратора вводим:

fsutil 8dot3name set 1

Шаг 5. Настройка средств обслуживания

Ни одна инфраструктура не может полноценно существовать без мониторинга и резервного копирования. Предупредить о возможной проблеме, узнать о последней раньше пользователей или иметь возможность восстановить данные — показатели высокой ответственности и профессионализма системного администратора.

Резервное копирование

Для файлового сервера все просто — необходимо резервировать все рабочие папки и файлы. Лучшим решением будет ежедневное копирование новых данных, и с определенной периодичностью (например, раз в месяц), создавать полный архив.

Мониторинг

1. Сетевую доступность сервера;
2. Свободное дисковое пространство;
3. Состояние жестких дисков.

Шаг 6. Тестирование

Тестирование состоит из 3-х основных действий:

1. Проверить журналы Windows и убедиться в отсутствие ошибок. В случае их обнаружения, необходимо устранить все проблемы.
2. Выполнить действия анализатора соответствий рекомендациям.
3. Провести живой тест работы сервиса с компьютера пользователя.

How Domain Controllers Are Located in Windows

This article describes the mechanism used by Windows to locate a domain controller in a Windows-based domain.

This article applies to Windows 2000. Support for Windows 2000 ends on July 13, 2010. The Windows 2000 End-of-Support Solution Center is a starting point for planning your migration strategy from Windows 2000. For more information, see the Microsoft Support Lifecycle Policy.

Original product version: В Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: В 247811

Summary

This article details the process of locating a domain by its DNS-style name and its flat-style (NetBIOS) name. The flat-style name is used for backward compatibility. In all other cases, DNS-style names should be used as a matter of policy. This article also addresses troubleshooting the domain controller location process.

More information

This sequence describes how the Locator finds a domain controller:

On the client (the computer that is locating the domain controller), the Locator is initiated as a remote procedure call (RPC) to the local Netlogon service. The Locator DsGetDcName application programming interface (API) call is implemented by the Netlogon service.

The client collects the information that is needed to select a domain controller and passes the information to the Netlogon service by using the DsGetDcName call.

The Netlogon service on the client uses the collected information to look up a domain controller for the specified domain in one of two ways:

For a DNS name, Netlogon queries DNS by using the IP/DNS-compatible Locator—that is, DsGetDcName calls the DnsQuery call to read the Service Resource (SRV) records and «A» records from DNS after it appends the domain name to the appropriate string that specifies the SRV records.

A workstation that is logging on to a Windows-based domain queries DNS for SRV records in the general form:

Active Directory servers offer the Lightweight Directory Access Protocol (LDAP) service over the TCP protocol. Therefore, clients find an LDAP server by querying DNS for a record of the form:

For a NetBIOS name, Netlogon performs domain controller discovery by using the Microsoft Windows NT version 4.0-compatible Locator (that is, by using the transport-specific mechanism (for example, WINS).

In Windows NT 4.0 and earlier, «discovery» is a process for locating a domain controller for authentication in either the primary domain or a trusted domain.

The Netlogon service sends a datagram to the computers that registered the name. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP User Datagram Protocol (UDP) search. (UDP is the connectionless datagram transport protocol that is part of the TCP/IP protocol suite. TCP is a connection-oriented transport protocol.)

Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.

UDP allows a program on one computer to send a datagram to a program on another computer. UDP includes a protocol port number, which allows the sender to distinguish among multiple destinations (programs) on the remote computer.

• Each available domain controller responds to the datagram to indicate that it is currently operational and returns the information to DsGetDcName.
• The Netlogon service caches the domain controller information so that subsequent requests need not repeat the discovery process. Caching this information encourages consistent use of the same domain controller and a consistent view of Active Directory.

When a client logs on or joins the network, it must be able to locate a domain controller. The client sends a DNS Lookup query to DNS to find domain controllers, preferably in the client’s own subnet. Therefore, clients find a domain controller by querying DNS for a record of the form:

After the client locates a domain controller, it establishes communication by using LDAP to gain access to Active Directory. As part of that negotiation, the domain controller identifies which site the client is in based on the IP subnet of that client. If the client is communicating with a domain controller that is not in the closest (most optimal) site, the domain controller returns the name of the client’s site. If the client has already tried to find domain controllers in that site (for example, when the client sends a DNS Lookup query to DNS to find domain controllers in the client’s subnet), the client uses the domain controller that is not optimal. Otherwise, the client performs a site-specific DNS lookup again with the new optimal site name. The domain controller uses some of the directory service information for identifying sites and subnets.

After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client.

After the client has established a communications path to the domain controller, it can establish the logon and authentication credentials and, if necessary for Windows-based computers, set up a secure channel. The client then is ready to perform normal queries and search for information against the directory.

The client establishes an LDAP connection to a domain controller to log on. The logon process uses Security Accounts Manager. Because the communications path uses the LDAP interface and the client is authenticated by a domain controller, the client account is verified and passed through Security Accounts Manager to the directory service agent, then to the database layer, and finally to the database in the Extensible Storage engine (ESE).

Troubleshooting the Domain Locator Process

To troubleshoot the domain locator process:

Check Event Viewer on both the client and the server. The event logs may contain error messages indicating that there is a problem. To view Event Viewer, click Start, point to Programs, point to Administrative Tools, and then click Event Viewer. Check the System log on both the client and the server. Also, check the Directory Service logs on the server and DNS logs on the DNS server.

Check the IP configuration by using the ipconfig /all command at a command prompt.

Use the Ping utility to verify network connectivity and name resolution. Ping both the IP address and the server name. You may also want to ping the domain name.

Use the Netdiag tool to determine whether networking components are working correctly. To send detailed output to a text file, use the following command:

netdiag /v >test.txt
Review the log file, looking for problems, and investigate any implicated components. This file also contains other network configuration details.

To fix minor problems, use the Netdiag tool with the following syntax: netdiag /fix .

Use the nltest /dsgetdc:domainname command to verify that a domain controller can be located for a specific domain.

Use the NSLookup tool to verify that DNS entries are correctly registered in DNS. Verify that the server host records and GUID SRV records can be resolved.

For example, to verify record registration, use the following commands:
nslookup servername. childofrootdomain. rootdomain.com
nslookup guid._msdcs. rootdomain.com

If either of these commands does not succeed, use one of the following methods to reregister records with DNS:

• To force host record registration, type ipconfig /registerdns.
• To force domain controller service registration, stop and start the Netlogon service.

To detect domain controller problems, run the DCdiag utility from a command prompt. The utility runs a number of tests to verify that a domain controller is running correctly. Use this command to send the results to a text file: dcdiag /v >dcdiag.txt

Use the Ldp.exe tool to connect and bind to the domain controller to verify appropriate LDAP connectivity.

If you suspect that a particular domain controller has problems, it may be helpful to turn on Netlogon debug logging. Use the NLTest utility by typing this command: nltest /dbflag:0x2000ffff . The information is then logged in the Debug folder in the Netlogon.log file.

If you still have not isolated the problem, use Network Monitor to monitor network traffic between the client and the domain controller.

References

For more information, see the Windows Resource Kit, Chapter 10, «Active Directory Diagnostic, Troubleshooting, and Recovery.»