Папки в корне C:\ на Windows 10 в домене Active Directory

Чаще всего папки в корне C:\ на рабочем ПК в домене Active Directory — это не «вредные» каталоги, а результат доменных политик: Folder Redirection, Group Policy Preferences или логон‑скриптов, которые создают/мапят пользовательские папки в системном контексте (поэтому владельцем часто оказывается SYSTEM). «Неизвестная группа» в списке безопасности появляется потому, что ACL содержит SID или доменную группу, которую локальная машина не может корректно сопоставить. Принудительное удаление без выяснения источника часто приводит к потере данных и повреждению профиля — сначала делайте резервную копию и разбирайтесь с GPO/файловым сервером.

Содержание

• Что это за папки и откуда они берутся?
• Почему владелец — SYSTEM и “неизвестная группа” в ACL
• Какие последствия при принудительном удалении?
• Как безопасно выяснить и устранить проблему — чеклист
• Команды и примеры (takeown, icacls, robocopy, PowerShell)
• Частые ошибки и рекомендации администратору
• Источники
• Заключение

Что это за папки в корне C:\ — связь с Active Directory и GPO

Коротко: это обычно следствие настроек домена — Folder Redirection (перенаправление специальных папок пользователя) или настройка через Group Policy Preferences (GPP) / логон‑скрипты, которые создают каталоги (иногда с переменной %LogonUser%) прямо в корне диска или монтируют удалённую папку в виде точки. При Folder Redirection фактические данные лежат на SMB‑шаре, а клиент «видит» их как свои документы; при GPP/скриптах администратор мог явно создать папки в C:\ для каждого пользователя — отсюда множество похожих каталогов с персональными файлами внутри. Подробнее о механике перенаправления — см. практическое руководство по настройке Folder Redirection на winitpro и пояснения по GPP на Habr.

Какие варианты чаще встречаются:

• Folder Redirection → данные физически находятся на файловом сервере (UNC); клиент отображает их в профиле пользователя. Подробности по поведению и полям ACL — в обзоре на ITDog.
• Group Policy Preferences (создание папок с %LogonUser%) или логон‑скрипты, выполняющиеся в системном контексте и создающие каталоги в C:.
• Кэш Offline Files (если включён) — локальная копия сетевых папок. При проблемах с синхронизацией кэша вы увидите «лишние» папки с данными.

Почему владелец — SYSTEM и “неизвестная группа” в ACL

Почему SYSTEM?

• Многие операции GPO/GPP и некоторые служебные задачи выполняются под системным учётным записом (LocalSystem) на клиенте или на сервере. Если папку создал процесс в контексте SYSTEM, владельцем станет именно SYSTEM.
• В случае, когда папки — это точки монтирования/стаб для сетевой шаре, владельцем может быть SYSTEM/администратор файлового сервера; клиент видит этот владелец локально.

Почему «неизвестная группа»?

• В ACL записан SID группы или доменная группа, которую текущая машина не может разрешить в имя (например, группа существует только на контроллере домена/в другом домене или нет связи с DC). Microsoft описывает похожие случаи с отображением некорректных имён групп в окнах безопасности — см. KB на support.microsoft.com.
• Если клиент не может связаться с контроллером домена или проверка доверия/контекста отличается, SID останется неразрешённым и появится как «неизвестная учётная запись/SID».

Итого: такое сочетание SYSTEM + неизвестная группа — обычный симптом: каталог создан системой/сервером, а права на него присвоены доменными SID, которые локальная машина не смогла корректно показать.

Какие последствия при принудительном удалении?

Удалять такие папки «с амвона» рискованно. Возможные последствия:

• Потеря пользовательских данных. Если каталог фактически указывает на сетевой ресурс (Folder Redirection) или синхронизирован с файловым сервером, удаление на клиенте может удалить данные на сервере (в зависимости от прав и способа мапинга).
• Повреждение профиля пользователя. Удаление перенаправленных папок может привести к отсутствию документов, «битым» путям в профиле и ошибкам в приложениях.
• Повторное создание пустых папок. Если источник — GPO/GPP, политика просто создаст пустые папки заново при следующем применении, а данные уже будут утеряны.
• Нарушение синхронизации Offline Files (если включён кэш) — конфликт данных, несинхронизированные изменения.
• Риск повредить системные функции. Если по ошибке применить takeown/icacls к системным каталогам, можно сломать права и нарушить работу ОС.

Короче: удаление без бэкапа и без отключения политики — частая причина инцидентов. Перед любыми принудительными действиями создайте резервную копию и проконсультируйтесь с администратором домена или владельцем файлового сервера.

Как безопасно выяснить и устранить проблему — чеклист

1. Остановитесь. Не удаляйте и не меняйте владельца, пока не сделаете резервную копию.
2. Выясните источник:

• Получите отчёт политик: запустите на машине gpresult /h "%temp%\gp-report.html" или gpresult /r и посмотрите применённые GPO для пользователя.
• Откройте оснастку Resultant Set of Policy (rsop.msc) или проверьте в GPMC настройки User Configuration → Windows Settings → Folder Redirection.

3. Проверьте, являются ли папки ссылками на сетевой ресурс:

• Посмотрите свойства папки, раздел «Общие» / «Сеть», проверьте путь (если это монтированная точка или reparse point).

4. Просмотрите ACL и владельца:

• icacls "C:\ИмяПапки" — покажет SID/разрешения.
• PowerShell: Get-Acl "C:\ИмяПапки" | Format-List

5. Сделайте резервную копию содержимого (копируйте на защищённый файловый ресурс или на другой сервер):

• Пример: robocopy "C:\ИмяПапки" "\\fs01\backup\ИмяПапки" /MIR /COPYALL /R:3 /W:5 — это сохранит файлы и метаданные.

6. Исправляйте на стороне домена/файлового сервера, а не локально:

• Если виноват Folder Redirection — измените или отключите политику (параметр редиректа), затем выполните логон/разлогон пользователя и убедитесь, что данные встали на место.
• Если виноват GPP (создание папок) — правьте Preference (удалите/измените правило) в GPMC. Habr даёт примеры создания папок через GPP https://habr.com/ru/post/278659/.

7. Если всё проверено и нужно снять блокировку локально — делайте это после бэкапа:

• Меняем владельца и права (только при необходимости) и затем удаляем. Подробный пример команд — ниже (см. раздел с командами). Рекомендуется сначала тестировать на одной машине.

Если у вас нет прав или опыта, обратитесь к администратору домена — многие шаги (изменение GPO, проверка шар) требуют прав администратора AD/файлового сервера.

Команды и примеры (takeown, icacls, robocopy, PowerShell)

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

Просмотр политик:

gpresult /h "%temp%\gp-report.html"

Просмотр ACL и владельца:

icacls "C:\FolderName"

или в PowerShell:

Get-Acl "C:\FolderName" | Format-List

Резервное копирование с сохранением прав:

robocopy "C:\FolderName" "\\fs01\backup\FolderName" /MIR /COPYALL /R:3 /W:5 /LOG:"C:\robocopy.log"

Принудительная смена владельца и выдача прав (только после бэкапа и если вы уверены):

takeown /F "C:\FolderName" /R /D Y
icacls "C:\FolderName" /grant Administrators:F /T

Подробное объяснение команд takeown/icacls — см. практическое руководство на Remontka.pro.

PowerShell (альтернатива для смены владельца):

$acl = Get-Acl "C:\FolderName"
$acl.SetOwner([System.Security.Principal.NTAccount]"BUILTIN\Administrators")
Set-Acl "C:\FolderName" $acl

Ещё: если вы видите в icacls SID вместо имени — это признак того, что группа/учётная запись не разрешается локально (см. KB Microsoft по некорректным именам групп: support.microsoft.com).

Частые ошибки и рекомендации администратору

• Ошибка: сразу брать и менять владельца SYSTEM на всех папках. Результат: потеря системных прав, возможный сбой служб. Совет: не трогайте папки вроде C:\Windows, C:\Users или другие системные каталоги.
• Ошибка: удалять папки до проверки, где лежат фактические данные. Совет: всегда сначала бэкап.
• Ошибка: лечить клиента локально, не исправив GPO на контроллере. Совет: правки GPO/Preferences делайте в GPMC и тестируйте на OU/тестовой машине.
• Рекомендации: используйте rsop.msc/ gpresult, проверьте настройки Folder Redirection и Home Folder в AD (свойства пользователя), проверьте права и настройки шар на файловом сервере (share permissions vs NTFS). Для массовых исправлений — корректируйте политику, затем выполняйте миграцию данных/очистку.

Если сомневаетесь, работайте по шагам: выяснили источник → сделали бэкап → внесли корректировки в политику → проверили на одном пользователе → масштабировали.

Источники

1. https://winitpro.ru/index.php/2022/05/19/nastrojka-perenapravleniya-papok-windows-gpo/
2. https://itdog.info/perenapravlenie-papok-v-domene-active-directory-na/
3. https://habr.com/ru/post/278659/
4. https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/networking/problems-administrative-shares-missing
5. https://support.microsoft.com/ru-ru/topic/неправильное-имя-группы-active-directory-отображается-в-диалоговом-окне-дополнительные-параметры-безопасности-в-windows-7-с-пакетом-обновления-1-или-windows-server-2008-r2-с-пакетом-обновления-1-ffe5d141-afb0-cfc6-819a-7241a6345751
6. https://answers.microsoft.com/ru-ru/windows/forum/all/неопозна/68680415-6d59-4011-a2c7-45bd89ef4dd3
7. https://remontka.pro/take-ownership-windows/
8. https://glashkoff.com/kak-stat-vladeltsem-faylov-i-papok/
9. https://dell.com/support/kbdoc/ru-am/000138794/windows-server-исправление-базы-данных-active-directory-после-сбоя-контроллера-домена
10. https://learn.microsoft.com/ru-ru/troubleshoot/windows-client/networking/cannot-access-shared-folder-file-explorer

Заключение

Папки в корне C:\ на компьютере в домене Active Directory чаще всего — следствие доменных политик (Folder Redirection / GPP / логон‑скрипты) или кэша Offline Files; SYSTEM — типичный владелец, если каталог создан в системном контексте, а «неизвестная группа» — результат неразрешённых доменных SID. Удалять такие папки без анализа и бэкапа нельзя: можно потерять данные и повредить профиль пользователя. Действуйте по алгоритму: выяснить источник (gpresult/rsop), сделать резервную копию (robocopy), исправить политику на стороне AD/файлового сервера, затем аккуратно удалить остатки или сменить владельца при необходимости.