Глава 10. Управление совместными данными

Разделение данных с прочими пользователями в вашей сетевой среде является функциональной возможностью операционных систем компьютеров с самых ранних дней построения сетевых сред. Эта глава рассматривает функциональные возможности Windows Server 2022, которые делают возможным совместное использование файлов и папок, а также пользоваться разделяемыми вами данными.

Microsoft's LAN Manager было первым сетевым предложением компании. Он позволил компьютерам клиентов безопасно создавать, управлять и разделять файлы. Протокол LAN Manager для предоставления такой функциональности клиент/ сервер являлся ранней версией протокола SMB (Server Message Block, блока серверных сообщений).

SMB это протокол хранения файлового уровня, выполняющийся поверх TCP/IP. При помощи протокола SMB вы можете безопасно и надёжно совместно применять файлы и папки. Для увеличения надёжности серверов SMB вы можете устанавливать некий кластер и роль кластера файлового сервера. Простое кластерное решение это решение активный- пассивный - у вас имеется один участник кластера когда все прочие участники отказали. Это решение великолепно работает до тех пор пока доступны лежащие в его основе данные. SOFS (Scale-Out File Server, Горизонтально масштабируемый Файловый сервер) это основанное на кластере решение, являющееся активно- активным. Оба узла вашего кластера способны обслуживать клиентов кластера.

Эта глава показывает вам как реализовывать и применять имеющиеся функциональные возможности разделения данных между системами в Windows Server 2022.

В нашем первом рецепте, Управление полномочиями файла и папки NTFS, вы пользуетесь модулем Безопасности NTFS стороннего разработчика для настройки ACL и наследования ACL для файлов, содержащихся в NTFS в SRV1. В своём следующем рецепте, Настройка и работа с безопасностью файлового сервера SMB вы развёртываете упрочнённый файловый сервер SMB. Вы выполняете этот рецепт в SRV2.

iSCSI это популярная технология SAN (Storage Area Networking, Сетевых сред хранения данных). Многие производители SAN предоставляют iSCSI в качестве варианта доступа к хранимым в SAN данным. Существуют две стороны для iSCSI: сервер (цель iSCSI) и его клиент (инициатор iSCSI). В рецепте Создание цели iSCSI вы создаёте некую цель iSCSI в своём сервере SS1, в то время как в рецепте Применение цели iSCSI вы пользуетесь таким совместным диском iSCSI из SRV1 и SRV2.

FSRM (File System Resource Manager, Диспетчер ресурсов Файловой системы) это компонент Windows Server, разработанный в помощь управлению вами файловыми серверами. Вы можете применять FSRM для настройки квот пользователей на папки, установки фильтрации файлов и создания богатых отчётов.

В рецепты этой главы вовлечены несколько серверов - каждый рецепт описывает конкретные применяемые в нём серверы. Как и в прочих главах, все серверы являются участниками вашего домена Reskit.Org, в котором вы загрузили PowerShell 7 и VS Code. Вы можете установить их применяя сценарии настройки Reskit.Org из GitHub.

Все файлы и папки в файловой системе NTFS обладают неким ACL (Access Control List, Списком контроля доступа). ACL содержит ACE (Access Control Entries, Записями контроля доступа). Каждая ACE определяет полномочия к файлу или папке для некой учётной записи. Например, вы можете предоставить глобальной группы AD Продавцов полный контроль над файлом.

NTFS также позволяет неким файлу или папке наследовать полномочия из его родительской папки. Когда вы создаёте новую папку и далее создаёте внутри этой новой папки некий файл, такой новый файл наследует полномочия своей родительской папки. Вы можете управлять имеющимся ACL на предмет добавления или удаления полномочий и вы можете изменять наследование.

Существует ограниченное сопровождение PowerShell для управления полномочиями NTFS. PowerShell в реальности обладает командлетами Get-ACL и Set-ACL, однако создание создание конкретной индивидуальной ACE и управление интерфейсом требует (по умолчанию) применения .NET Framework. Более простой подход состоит в применении модуля стороннего разработчика, .NET Framework, который превращает управление ACE и ACL, включая работу с наследованием, намного более лёгким.

Данный рецепт пользуется SRV2, присоединённом к домену хосту в вашем домене Reskit.Org, в котором у вас имеются установленными PowerShell 7 и VS Code. Вам также требуется работающий DC1. В Главе 9, Управление хранилищем вы добавили несколько виртуальных дисков в SRV1 и SRV2 и настроили Реплику хранения. Вы создали устройств F: в обоих серверах. Репликация хранения должно реплицироваться с диска 1 (раздел F:) в SRV2 на диск 1 в SRV1 (в реальности некий скрытый раздел). Если ваш хост Hyper-V замедляется на физических ресурсах, попробуйте удалить такое партнёрство репликации.

На Шаге 1 вы выгружаете и устанавливаете модуль NTFSSecurity из Галереи PowerShell. Этот шаг не создаёт никакого вывода в консоль. На Шаге 2 вы рассматриваете те команды, которые предоставляет модуль NTFSSecurity со следующим выводом:

На Шаге 3 вы создаёте некую папку и файл внутри этой папки, что выдаёт такой вывод:

На Шаге 4 для получения ACL новой папки в пользуетесь командлетом Get-NTFSAccess и получаете такой вывод:

На Шаге 5 вы получаете значение ACL для файла F:\Secure1\Secure.Txt, что снабжает вас таким выводом:

На Шаге 6 вы создаёте глобальную группу, Sales, в своём домене Reskit.Org, если её ещё нет. Этот шаг остаётся без вывода. На Шаге 7 вы просматриваете эту группу Продаж из AD с подобным следующему выводом:

На Шаге 8 вы добавляете в явном виде ACE для Администраторов домена с полным контролем над папкой F:\Secure1. Затем, на Шаге 9 вы удаляете группу builtin\users из доступа к своему файлу Secure.txt. А потом, на Шаге 10 вы удаляете все наследуемые права из F:\Secure1. Наконец, на Шаге 11 , вы добавляете в явном виде доступ к папке F:\Secure1 для своей группы Продаж. Эти шаги не производят вывод.

На Шаге 12 вы изучаете и обновляете ACL для папки F:\Secure1, с подобным следующему выводом:

На Шаге 13 вы просматриваете и обновляете ACL для файла F:\Secure1\Secure.txt, примерно с таким выводом:

Как вы можете видеть на Шаге 2 , рассматривая Рисунок 10-01, в модуле NTFSSecurity имеется некоторое число командлетов. Вы можете пользоваться этими командлетами для установки ACL некоторого файла или какой- то папки и значение SACL (system access control list, списка контроля доступом системы), которое позволяет вам выполнять аудит доступа к файлу или папке. Также имеются улучшения командлетов, такие как Get-ChildItem2 и Get-Item2, которые вы можете найти полезными.

Следующим шагом в создании файлового сервера является установка всех необходимых функциональных возможностей в вашем сервере и затем его упрочнение. Для добавления всех компонентов, которые необходимы вам в файловом сервере вы применяете командлет Add-WindowsFeature. Затем для улучшения его настроек вы можете воспользоваться командлетом Set-SmbServerConfiguration.

Поскольку ваш файловый сервер может содержать чувствительные сведения, вам надлежит предпринять здравые шаги для того чтобы избежать ожидаемых механизмов атак и приспособить наиболее лучшие рекомендации по безопасности. Безопасность это хорошая вещь, однако всегда будьте бдительны! Блокируя свой файловый сервер SMB слишком сильно, вы можете заблокировать некоторых пользователей вообще в этом сервере.

SMB 1.0 обладает множеством уязвимостей и, в целом, его следует удалять. По умолчанию, Windows Server 2022 устанавливается с отключённым SMB 1.0. Помните, что когда вы запрещаете SMB 1.0, вы можете обнаружить, что более древние компьютеры (например, работающие под управлением Windows XP) утратят возможность доступа к совместным данным. Прежде чем блокировать какие бы то ни было настройки своего сервера, убедитесь что вы тщательно проверили свои изменения.

Этот рецепт пользуется SRV2, присоединённом к домену хостом в вашем домене Reskit.Org, в котором у вас установлены PowerShell 7 и VS Code. Вы также пользуетесь SRV2 и должны иметь работающим DC1.

На Шаге 1 вы добавляете компоненты файлового сервера в SRV2 с подобным следующему выводом:

На Шаге 2 для возврата установок своего сервера SMB для SRV2 вы пользуетесь командлетом Get-SmbServerConfiguration.

На Шаге 3 вы отключаете SMB 1.0 в явном виде. На Шаге 4 вы включаете цифровую подпись и шифрование всех относящихся к SMB пакетов данных. На Шаге 5 вы отключаете устанавливаемые по умолчанию совместные ресурсы сервера и рабочей станции, в то время как на Шаге 6 для улучшения безопасности вы отключаете оповещения сервера SMB. Эти четыре шага не производят вывод.

На Шаге 7, который также не выдаёт вывод, вы перезапускаете свою службу LanManServer, которая является службой Windows, которая предоставляет совместное использование ресурсов SMB.

На Шагах с 3 по 6 вы обновляете установленную конфигурацию своей службы SMB в большую безопасность. Протокол SMB 1.0 более не рассматривается безопасным. По умолчанию процесс установки ОС Windows никогда не включает версию 1, однако будет неплохо убедиться что он отключён. Цифровая подпись и шифрование всех пакетов SMB защищает против того что некто воспользуется сетевым снифингом для просмотра данных пакетов. Уведомления сервера SMB способны предоставлять дополнительные сведения потенциальных сетевым хакерам относительно всех служб в вашей сетевой среде.

На Шаге 7 после выполнения изменений в настройках службы SMB вы перезапускаете свою службу LanManWorkstation. Для вступления в действие всех изменений в настройках файлового сервера вам надлежит перезапускать эту службу.

Получив настроенной свою службу файлового сервера, следующим шагом в развёртывании файлового сервера является создание совместных ресурсов SMB и настройка их безопасности. На протяжении десятилетий администраторы пользовались командой net.exe для настройки совместно применяемых папок и прочего. Эта команда продолжает работать, однако вы можете найти более простым применение командлетов SMB, в особенности, когда вы автоматизируете развёртывание сервера SMB крупного масштаба.

Этот рецепт взглянет на создание совместного ресурса и настройку его безопасности в платформе Windows Server 2022 при помощи модуля PowerShell SMBServer. Вы также воспользуетесь командлетами из модуля NTFSSecurity (модуля стороннего разработчика, который вы выгрузили из Галереи PS).

Вы исполняете этот рецепт в своём файловом сервере SRV2, который вы настроили и упрочили в своём рецепте Настройка и работа с безопасностью файлового сервера SMB. В этом рецепте вы выдали в совместное пользование папку (C:\ITShare) из этого файлового сервера. Затем вы создали в этой папке C:\ITShare некий файл, который вы просто совместно применяете и установили ACL точно такими же для этого совместного ресурса. Для этого вы воспользовались командлетом Set-SMBPathAcl. Затем вы просмотрели установки ACL как для папки, так и для самого файла.

Данный рецепт пользуется универсальной группой безопасности Продаж, которую вы создали в своём домене Reskit.Org. Отсылаем вас к рецепту Управление безопасностью принтера из Главы 11, Управление печатью для ознакомления с фрагментом кода, который вы можете применять для создания соответствующей группы, применяемой в этом рецепте. В данном рецепте вы пользуетесь командлетом Get-NTFSAccess из NTFSSecurity, модуля стороннего разработчика, который вы выгрузили из Галереи PowerShell. Для получения дополнительных сведений относительно этого модуля и инструкций по его выгрузке обратитесь к рецепту Управление полномочиями файла и папки NTFS.

Этот рецепт применяет SRV2, присоединённый к домену хост в вашем домене Reskit.Org, в котором у вас установлены PowerShell и VS Code. Вам также следует иметь включённым DC1. Если вы ещё не создали универсальную группу Продаж, ознакомьтесь с рецептом Управление безопасностью принтера.

На Шаге 1 для выявления всех текущих совместных ресурсов SMB в SRV2, а также тем, какие учётные записи обладают доступом к этим совместным ресурсам, вы пользуетесь Get-SmbShare. Вот вывод с этого шага:

На Шаге 2 вы создаёте новую папку в устройстве C:\ и выставляете эту папку в совместный доступ в качестве \\SRV2\ITShare. Вот как выглядит вывод с этого шага:

Обладая созданным совместным ресурсом, вы далее настраиваете подробности доступа к этому совместному ресурсу. На Шаге 3 вы изменяете его с тем, чтобы он обладал описанием. При помощи Шага 4 вы устанавливаете нумерацию в этом ресурсе на основе доступа. Затем, на Шаге 5 вы обеспечиваете шифрование Windows всех данных, которые обмениваются через этот совместный ресурс. Затем, на Шаге 6 вы удаляете доступ к ITShare для группы Everyone. На Шаге 7 вы предоставляете группе Reskit\Administrator полномочия на чтение в ITShare. На Шаге 8 вы предоставляете самой ОС полный доступ к этому совместному ресурсу. На Шаге 9 вы предоставляете его создателю и владельцу всех файлов/ папок полный доступ к соответствующему файлу. Наконец, на Шаге 10 вы предоставляете группе Продаж доступ на чтение. Эти восемь этапов настройки не производят никакого вывода.

На Шаге 11 вы просматриваете установленный доступ к этому совместному ресурсу, что снабжает вас таким выводом:

Теперь, когда у вас имеется доступ к вашему совместному ресурсу с настройками как вам потребовалось, на Шаге 12 вы пользуетесь командой Set-SMBPathAcl чтобы заставить полномочия NTFS соответствовать настроенным полномочиям соответствующего совместного ресурса. На Шаге 13 вы создаёте новый файл в этой папке, разделяемой как ITShare, а затем на Шаге 14 обеспечиваете что этот файл сам по себе обладает тем же самым значением ACL, что и сам совместный ресурс. Эти три шага не производят вывод.

На Шаге 15 вы просматриваете свой файл, C:\ITShare\File.txt, что обеспечивает вам вывод, подобный приводимому ниже:

На Шаге 1 вы изучаете все доступные в SRV2 совместные ресурсы. В рецепте Настройка и работа с безопасностью файлового сервера SMB вы установили свою службу SMB на удаление всех устанавливаемых по умолчанию совместных ресурсов в SRV2. Единственный совместный ресурс, который вы наблюдаете на Шаге 1 IPC$, который Windows применяет для механизма взаимодействия через именованные конвейеры. Для получения дополнительных сведений относительно этого совместного ресурса отсылаем вас к https://docs.microsoft.com/troubleshoot/windows-server/networking/inter-process-communication-share-null-session.

На Шаге 4 вы установили нумерацию на основе доступа для своего ресурса ITShare. Эта настройка означает, что всякий просматривающий файлы или папки внутри этого совместного ресурса пользователь видит лишь те объекты, которым он обладает доступом. Эта настройка улучшает безопасность и минимизирует к Администратору такие вопросы как "Что это за файл/ папка, и почему у меня нет доступа к этим файлу/ папке?"

На Шаге 5 вы настроили для своего совместного ресурса ITShare шифрование. Этот шаг гарантирует что Windows осуществляет шифрование данных для всех передаваемых через этот совместный ресурс данных. Вы можете устанавливать это по умолчанию на уровне своего сервера или, как в данном случае, на уровне своего совместного ресурса.

В рецепте Настройка и работа с безопасностью файлового сервера SMB вы создали в SRV2 совместный ресурс. Данные, к которым вы получаете доступ при помощи разделения файлов SMB действуют и выглядят как имеющие локальный доступ файлы через Windows Explorer (Проводник) или консоль PowerShell.

В этом рецепте вы получаете доступ к совместному ресурсу ITShare из SRV2 в SRV1.

В этом рецепте вы пользуетесь SRV1, присоединённом к домену хостом в вашем домене Reskit.Org , в котором у вас имеются установленными PowerShell 7 и VS Code. Вы также применяете SRV2 и должны обладать работающим DC1. Вы ранее создали в SRV2 совместные ресурсы SMB, которые применяете в этом рецепте.

На Шаге 1 вы изучаете в SRV1 конфигурацию клиента SMB. Вот как выглядит вывод:

На Шаге 2 вы гарантируете что SRV1 требует подписанных пакетов SMB, вне зависимости от имеющихся настроек в сервере SMB (SRV1). На этом шаге нет никакого вывода.

На Шаге 3 вы изучаете NIC в SRV1 с приводимым ниже выводом:

На Шаге 4 вы пользуетесь командой net.exe для просмотра предоставляемых SRV2 совместных ресурсов. Вывод с этого шага выглядит так:

На Шаге 5 вы создаёте новое соответствие устройства SRV1, ставя в соответствие устройству R: совместный ресурс \\SRV2\ITShare, что создаёт следующий вывод:

На Шаге 6 вы просматриваете соответствия устройств в SRV1, что выглядит так:

На Шаге 7 вы просматриваете всё содержимое вашего совместного ресурса для обнаружения всех файлов, созданных в рецепте Настройка и работа с безопасностью файлового сервера SMB

На Шаге 8 вы просматриваете все имеющиеся подключения в SRV1. Этот шаг производит такой вывод:

На Шаге 4 вы применяете команду net.exe для просмотра предлагаемых SRV2 (из SRV1) совместных ресурсов. Модуль SMBShare не предоставляет командлета для просмотра предоставляемых удалённым хостом совместных ресурсов.

iSCSI это протокол стандарта отрасли, который реализует блочное хранилище поверх сетевой среды TCP/IP. При помощи iSCSI сервер или, так называемая цель, предоставляет том, совместно разделяемый через iSCSI некому клиенту iSCSI, также именуемому инициатором.

В оригинальном протоколе SCSI вы пользуетесь термином LUN (Logical Unit Number, номер логического устройства) чтобы ссылаться на подключаемый к шине SCSI отдельный физический диск. В iSCSI вы предоставляете каждому удалённо совместно используемому тому некого LUN iSCSI. Соответствующий клиент iSCSI затем рассматривает этот LUN просто как иное дисковое устройство, подключаемое к вашей локальной системе. Со стороны клиента iSCSI у вас имеется возможность управлять таким диском ровно также как локально подключаемым хранилищем. Windows Server 2022 содержит как функциональные возможности цели iSCSI (сервера), так и инициатора iSCSI (клиента).

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

В iSCSI некая цель это отдельный диск, к которому ваш клиент получает доступ при помощи своего клиента iSCSI. Хост сервера цели iSCSI это одна или более целей, где каждая цель iSCSI это эквивалент некого LUN в SAN Fiber Channel.

Вы можете применять iSCSI в неком кластере серверов Hyper-V. Эти серверы в этом кластере могут применять свой инициатор iSCSI для доступа к некой цели iSCSI. Используемая через совместный том кластера (Cluster Shared Volume), такая разделяемая цель iSCSI совместно применяется узлами в неком отказоустойчивом кластере, что делает возможным всем ВМ из такого кластера обладать высокой доступностью.

Данный рецепт применяет SS1, присоединённый к домену хост из вашего домена Reskit.Org, в котором у вас установлены PowerShell 7 и VS Code.

На Шаге 1 вы устанавливаете компонент цели iSCSI в своём сервере SS1 со следующим выводом:

На Шаге 2 вы изучаете настройки сервера целей iSCSI с выводом, который выглядит так:

На Шаге 3 вы создаёте в SS1 некую папку для содержания необходимого вам виртуального диска iSCSI, что не производит вывод. На Шаге 4 вы создаёте виртуальный диск iSCSI (по существу LUN) с выводом, который выглядит таким образом:

На Шаге 5 вы определяете какие компьютеры могут применять созданный целевой iSCSI виртуальный диск с подобным следующему выводом:

На окончательном шаге, Шаге 6, вы определяете соответствие своего целевого диска, что не производит вывод. Этот шаг устанавливает соответствие между неким названием цели iSCSI (ITTarget) и тем локальным путём, в котором вы храните свой виртуальный жёсткий диск iSCSI.

По умолчанию Windows не устанавливает функциональные возможности цели iSCSI, но как вы видите на Шаге 1, вы можете воспользоваться Install-WindowsFeature для добавления такой функциональности в этом сервере хранения.

Когда вы создаёте некую цель iSCSI, вы создаёте название этой цели и целевого виртуального жёсткого диска по отдельности, а затем, на Шаге 6, вы устанавливаете соответствие названия цели iSCSI местоположению его файла. В промышленном применении вы применяете отдельный набор (устойчивых к отказам) дисков для содержания сведений iSCSI, возможно, применяя Пространства хранения для создания отказоустойчивых виртуальных дисков.

Windows предоставляет встроенный компонент клиента iSCSI которым вы пользуетесь командой Connect-IscsiTarget для подключения своего клиента iSCSI к серверу iSCSI и запуску применения такого диска как если бы он был подключён локально.

Этот рецепт пользуется SRV1, присоединённым к домену хостом в вашем домене Reskit.Org, в котором вы установили PowerShell 7 и VS Code. Вы также применяете SS1 и должны обладать включённым DC1. Ранее вы создали некую цель iSCSI (в SS1) и теперь вы пользуетесь встроенным инициатором iSCSI для доступа к диску iSCSI. Вы исполняете этот рецепт в SRV1.

На Шаге 1 вы настраиваете службу iSCSI для запуска когда SRV1 запускается автоматически и затем в явном виде стартуем эту службу iSCSI. У этого шага нет вывода в консоль.

На Шаге 2 вы настраиваете свой портал iSCSI в SS1, что выглядит следующим образом:

На Шаге 3 вы находите и просматриваете LUN ITTarget из SS1. Вот вывод с этого шага:

На Шаге 4 вы подключаетесь из SRV1 к цели iSCSI в SS1, что выглядит так:

На Шаге 5 вы применяете Get-Disk для просмотра диска iSCSI с SRV1 с приводимым далее выводом:

На Шаге 6 вы обеспечиваете свой диск iSCSI в рабочем состоянии и доступным на Чтение/ Запись, шаг не создающий вывод. На Шаге 7 вы создаёте новый том на диске iSCSI, что выглядит так:

На окончательном шаге, Шаге 8, вы создаёте папку в этом диске iSCSI. Затем вы создаёте файл и просматриваете этот файл, что приводится ниже:

Применение диска iSCSI достаточно простое - подключаемся к необходимой цели iSCSI и управляете этим дисковым томом локально. После подключения вы можете форматировать его с файловой системой и затем пользоваться ею для хранения данных. В промышленном применении вы можете не пользоваться хостом Windows Server для обслуживания в качестве цели iSCSI. Многи производители SAN (storage area network, сетевых сред хранения) добавляют функциональность iSCSI в их предложения SAN. В предложении SAN вы можете воспользоваться имеющимся инициатором iSCSI для доступа к такому SAN через iSCSI, хотя некоторые производители SAN могут предоставлять некие обновлённые инициаторы iSCSI для применения вами.

FSRM (File Server Resource Manager, Диспетчер ресурсов Файлового сервера) это компонент Windows Server, которое оказывает вам содействие в управлении Файловыми серверами. FSRM обладает тремя функциональными возможностями:

В данном рецепте вы установите FSRM, выполните некие общие настройки, а затем поработаете с мягкими и жёсткими квотами.

В этом рецепте применяется SRV1, присоединённый к домену хост в вашем домене Reskit.Org, в котором у вас имеются установленными PowerShell 7 и VS Code. Вам следует обладать включённым DC1 для предоставления аутентификации SRV1.

FSRM обладает функциональными возможностями, которые отправляют сообщения электронной почты в некий сервер SMTP. Чтобы проверить такие функции, как показано в этом рецепте, вам потребуется некий сервер электронной почты с тем чтобы FSRM имел возможность отправлять электронные письма.

Для перенаправления электронных писем в некий почтовый сервер SMTP мы применяем Internet Information Server внутри Windows Server. Этот рецепт настраивает FSRM на отправку почты в хост (SMTP.Reskit.Org), который затем перенаправляет такую почту в бесплатную службу электронной почты в https://www.sendgrid.com. Для получения дополнительных сведений относительно того как настроить SendGrid для перенаправления необходимых электронных почтовых сообщений, обратитесь к https://tfl09.blogspot.com/2020/04/setting-up-smtp-relay-using-sendgrid.html. Если у вас имеется некий сервер SMTP, который получает почту из FSRM, тогда поменяйте этот рецепт на использование этого сервера.

На Шаге 1 для добавления в SRV1 компонента FS-Resource-Manager вы пользуетесь командлетом Install-WindowsFeature, что выглядит следующим образом:

На Шаге 2 вы настраиваете подробности SMTP, включая название сервера SMTP и адреса From и Admin. Этот шаг не производит вывод. На Шаге 3 для проверки обработки электронной почты SMTP вы пользуетесь командлетом Send-FsrmTestEmail. Этот шаг не производит вывод на консоль, однако должен сформировать некое почтовое отправление, которое выглядит подобным образом:

На Шаге 4 вы создаёте новый шаблон квотирования FSRM для жёсткого предела квотирования в 10 МБ. Вот вывод с этого шага:

На Шаге 5 вы просматриваете все доступные шаблоны квотирования FSRM и получаете такой вывод:

На Шаге 6 вы создаёте новую папку, C:\Quota. На Шаге 7 вы собираете действие FSRM, которое отправляет электронное потовое сообщение всякий раз, когда пользователь превышает значение квоты. На Шаге 8 вы создаёте некое пороговое значение FSRM (какой предел значения мягкого квотирования может применять пользователь прежде чем включается нарушение квотирования). Эти ри шага не производят консольного вывода.

На Шаге 9 вы строите квотирование для своей папки C:\Quota с подобным приводимому ниже выводом:

На Шаге 10 вы проверяете значение мягкого предела квотирования в 85%. Сначала вы создаёте некий новый файл (C:\Quota\Demo1.Txt), который ниже значения предела мягкого квотирования. Затем вы создаёте второй файл (C:\Quota\Demo2.Txt), который пользуется большим чем значение мягкого предела квотирования. На этом этапе нет никакого консольного вывода, однако FSRM выявляет что вы превысили значение мягкого предела квотирования и вырабатывает сообщение электронной почты, которое выглядит следующим образом:

На Шаге 11 вы пробуете создать некий дополнительный файл, C:\Quota\Demo3.txt, выводя значение массива $S в файл, что в результате приводит к превышению жёсткого предела квотирования. Вы должны обнаружить приводимое ниже сообщение вывода:

На Шаге 12 вы изучаете имеющиеся в вашей папке C:\Quota файлы, что выглядит следующим образом:

В данном рецепте вы настроили и проверили как мягкое, так и жёсткое квотирование FSRM. При установленном мягком квотировании вы настраиваете FSRM на отправку некого электронного письма с информированием получателя что он превысил некую квоту. Вы можете пожелать отправлять электронное почтовое сообщение либо администратору, либо превысившему установленное пороговое значение квотирования пользователю. Для установленной жёсткой квоты FSRM фиксирует записи журнала событий приложений и останавливает сохранение превышающих данных пользователя. Значения квотирования, настроенные в этом рецепте малы и, скорее всего, не будут применяться в промышленной среде. Однако замените, скажем, 10 МБ на 10 ГБ, что не сложно исполнить.

На Шаге 1 вы установили новый компонент Windows в SRV1. Время от времени вы можете обнаруживать, что процесс установки просто стопорится и не завершается. В подобных ситуациях выполните повторно эту команду в новой консоли PowerShell или перезагрузите свой сервер, что сделает доступным добавление нового компонента.

На Шаге 4 вы создаёте некий новый шаблон квотирования FSRM. Вы можете наблюдать этот новый шаблон в вырабатываемом на Шаге 5 выводе. Обратите внимание, что этот шаблон квотирования применяется для жёсткого предела квотирования, а не для мягкого предела квотирования.

На Шаге 12 вы изучаете свою папку C:\Quot. Обратите внимание, что для вашего третьего файла (который вы попытались создать на Шаге 11), Windows не сохранил весь файл целиком. Когда вы планируете выставление жёсткого квотирования, вы должны обеспечить понимание своими пользователями такого воздействия превышения всяких жёстких пределов квотирования.

Отчётность это полезная и часто упускаемая из виду функциональная возможность FSRM. FSRM определяет некоторые базовые типы отчётов, которыми вы можете пользоваться. Эти отчёты могут либо вырабатываться немедленно (и они носят название интерактивных) или же по некоторому расписанию. Последнее заставляет FSRM вырабатывать отчёты еженедельно или ежемесячно.

FSRM производит отчёты с фиксированной схемой, не подлежащей изменению. FSRM способен возвращать одни и те же сведения, содержащиеся как в неком отчёте HTML, так и в виде документа XML. Вы можете пользоваться таким документом XML для создания отчёта тем способом, который требуется вам.

Этот рецепт пользуется SRV1, присоединённом к домену хостом в вашем домене Reskit.Org, в котором у вас имеются установленными PowerShell 7 и VS Code. В нашем предыдущем рецепте, Реализация квот FSRM, вы установили FSRM в SRV1.

На Шаге 1 вы создаёте новый отчёт FSRM для обнаружения больших файлов (с размером более 10 МБ) с своём устройстве C:\Quota. Вывод выглядит примерно так:

На Шаге 2 вы просматриваете все доступные отчёты со следующим выводом:

На Шаге 3 вы изучаете все завершённые отчёты, которые выводились в вашу папку C:\StorageReports. Вывод выглядит как- то так:

На Шаге 4 вы изучаете свой отчёт о крупных файлах в установленном по умолчанию браузере, что выглядит следующим образом:

На Шаге 5 вы выделяете из XML файла отчёта критически важные сведения и выводите их в свою консоль. Ниже приведён этот вывод.

На Шаге 6 вы создаёте новую запланированную задачу для ежемесячного исполнения. Задача исполняет отчёт FilesbyFileGroup. Этот шаг не производит вывод.

На Шаге 7 вы изучаете подробности своей плановой задачи со следующим выводом:

На Шаге 8 вы выполняете эту плановую задачу немедленно и получаете такой вывод:

На Шаге 9 после завершения выполнения отчёта со стороны FSRM вы наблюдаете вывод этого отчёта, который подобен приводимому ниже:

На финальном шаге этого рецепта, Шаге 10 , вы просматриваете в своём браузере полученный отчёт, C:\Quota что выглядит следующим образом:

На Шаге 1 вы создаёте новый интерактивный отчёт FSRM. FSRM немедленно запускает исполнение этой команды. Когда вы просматриваете содержимое папки отчётов, например, на Шаге 3, вы можете изначально не наблюдать никакого вывода отчёта. Для производства соответствующего отчёта FSRM требуется определённое время, а потому стоит подождать.

На Шаге 4 вы просматриваете при помощи своего браузера HTML отчёт, созданный FSRM. В зависимости от настроек вашего хоста вы можете обнаружить предложение ответить какое именно приложение вы желаете применить для просмотра своего отчёта.

Как вы можете видеть на основании данного рецепта, FSRM создаёт вывод отчёта как в формате HTML, так и в формате XML. У вас нет возможности изменения формата HTML, но он, скорее всего достаточно хорош для большинства случаев. Если вы пожелаете определённый формат или только некоторые из данных, вы можете получит те же самые сведения из XML и отформатировать их под свои потребности.

FSRM обладает вариантом отслеживания файлов. Такая функциональная возможность позволяет вам контролировать те типы файлов, которые вы позволяете сохранять в своём файловом сервере. Например, вы можете определить отслеживание файлов для запрета пользователю сохранения в своём файловом сервере музыкальных файлов (файлов с расширениями .MP3 или .FLAC). При помощи отслеживания файлов, когда пользователь пробует сохранить такой файл как GD71-02-18.T09.FLAC, FSRM препятствует сохранению такого файла.

Для настройки отслеживания файлов FSRM вам потребуется определить ту папку, которая подлежит защите FSRM и шаблон отслеживания файлов, который описывает те характеристики файлов, которые подлежат блокированию FSRM. FSRM поступает с пятью встроенными шаблонами экранирования файлов. Вы можете создавать дополнительные шаблоны под свои потребности.

Всякий шаблон экранирования файла содержит некий набор групп файлов. Каждая группа файлов содержит некий набор расширений файлов, которые способен блокировать FSRM. FSRM поставляется с 11-ю встроенными группами файлов, которые покрывают общие типы содержимого и могут обновляться и расширяться.

Одна из встроенных групп файлов FSRM это файлы аудио и видео. Эта группа содержит широкое разнообразие расширений файлов аудио и видео, в том числе, .AAC, .MP3, .FLAC и прочие. Что примечательно, данная группа не блокирует файлы .SHN (Shorten). Вы запросто можете добавить это расширение в соответствующую группу файлов, если пожелаете.

Обратите внимание, что отслеживание файлов работает исключительно на основании расширений файлов. FSRM, к примеру, способен блокировать сохранение вами такого файла, как GD71-02-18.T09.FLAC. Однако если вы попытаетесь сохранить этот файл как GD71-02-18.T09.CALF, FSRM позволит вам сохранить такой файл. Экранирование файлов FSRM не изучает сам выйл для выяснения значения реального типа файла. В большинстве случаев экранирование файлов останавливает наиболее очевидные политики нарушений.

Этот рецепт пользуется SRV1, присоединённом к домену хостом в вашем домене Reskit.Org, в котором у вас имеются установленными PowerShell 7 и VS Code. В одном из предыдущих рецептов, Реализация квот FSRM, вы установили FSRM в SRV1.

На Шаге 1 вы изучаете изначально установленные группы файлов FSRM. Вот вывод с этого шага:

На Шаге 2 вы изучаете встроенные шаблоны экранирования файлов FSRM. Вот как это выглядит:

На Шаге 3 вы создаёте новую папку для проверки отслеживания файлов FSRM, что не производит вывода. На Шаге 4 вы создаёте новое экранирование файла FSRM. Вот что вы получаете в выводе:

Для проверки отслеживания файла, на Шаге 5 вы копируете notepad.exe из папки Windows в свою папку экранирования файлов с приводимым ниже выводом:

На Шаге 6 вы настраиваете активное уведомление электронным письмом для указания вам всякий раз на попытку, когда пользователь пробует сохранять какой- то исполняемый файл в вашей экранированной папке. Этот шаг не производит вывод.

На Шаге 7 вы изучаете пределы уведомлений FSRM со следующим выводом:

Для ускорения создания уведомления электронной почтой, на Шаге 8 вы снижаете пределы уведомлений до 1 секунды. Этот шаг не производит вывод.

На Шаге 9 вы проверяете обновлённое экранирование файла и повторно пытаетесь сохранить некий исполняемый файл в своей отслеживаемой папке. В результате вы получаете такой вывод:

Обладая настроенным уведомлением электронным письмом для экранирования фалов, на Шаге 10 вы просматриваете выработанное электронное письмо, которое выглядит подобным образом:

На Шаге 1 вы рассмотрели те расширения файлов, которые FSRM распознаёт по умолчанию. Это охватывает большинство ситуаций. Небольшим упущением является то, что аудио и видео файлы не содержат расширения SHN. Файлы SHN это аудио файлы без потерь данных, которые пользуются алгоритмом сжатия Shorten. Вы можете обнаружить тучу легальных записей концертов на основе SHN множества групп, например, The Grateful Dead. По этой причине в промышленной среде вам потребуется обновить эту файловую группу FSRM чтобы позволить отслеживать файлы SHN, когда вы применяете данную файловую группу для экранирования файлов.

Функция отслеживания файлов позволяет предотвращать случайное сохранение пользователями файлов, нарушающих правила хранения файлов в вашей организации. Например, ваша организация может оговаривать, что пользователи не могут сохранять аудио или видео файлы в файловом сервере организации. Когда некий пользователь "случайно" сохраняет некий файл MP3, FSRM вежливо ему откажет. Тем не менее, как отмечалось ранее, отслеживание файлов основывается исключительно на расширениях файлов. Тем самым, если пользователь сохраняет файл и изменяет его расширение, скажем, на 3MP, FSRM не сработает. Естественно, поступая таким образом, данный пользователь намеренно нарушает политику организации, что может ограничить его карьеру.