Если вы столкнулись с проблемой удаления папки с компьютера под управлением Windows, при этот система выдает сообщение вроде "Не удалось найти элемент", "Папка не пуста" или вроде того, то может помочь следующий способ:
Берем архиватор, например, Winrar, и архивируем эту папку, при этом в свойствах указываем "Удалить файлы после упаковки". После архивации папка будет удалена, затем удаляем и полученный архив.
Ошибка 800B0001 при попытке проверки обновлений Windows как правило возникает по "криптографической" причине - проблемы с сертификатами или подписями файлов WSUS.
Проверьте, не установлено ли на клиентских компьютерах какое-либо криптографическое ПО, например, КриптоПРО. Возможно, причина будет именно в нем - удалите его или обновите до более новой версии. В моем случае проблема была вызвана КриптоПРО 3.6, помогло обновление до версии 3.9. Существует "Исправление для устранения проблем с Windows update для КриптоПро CSP 3.6, 3.6 R2 и 3.6 R3", но оно мне не помогло.
Если после установки указанных обновлений на клиентских компьютерах при поиске обновлений возникает ошибка 80244010, повторите поиск 2-3 раза, как правило, ошибка уходит. Подробнее об ошибке 80244010 тут.
После удаления одного знаменитого антивируса столкнулся с проблемой - перестали устанавливаться VPN-соединения с ошибкой 720: "Не удается подключится к удаленному компьютеру. Возможно потребуется изменение сетевой настройки подключения". При этом в Диспетчере устройств можно было увидеть устройства "Мини-порт глобальной сети (IP)", "Мини-порт глобальной сети (IPv6)" и "Мини-порт глобальной сети (Сетевой монитор)" с желтым треугольником предупреждения о невозможности запуска с ошибкой 10. Инициализация tcp/ip и winsock проблему не решила. В итоге проблему решил следующим образом:
1) Заходим с Свойства этих нерабочих устройств и заменяем их драйвер на "Адаптер замыкания на себя Microsoft KM-TEST". Делается это через закладку Драйвер->Обновить->Выполнить поиск драйверов на этом компьютере->Снимаем галку "Только совместимые устройства" и выбираем указанный драйвер. На предупреждение не обращаем внимания. Нужно это для того, чтобы система позволила удалить эти устройства и переустановила их заново - без этого система удалить их не дает. 2) Удаляем все устройства, на которых заменили драйвер. 3) Делаем рескан железа (Обновить конфигурацию оборудования), система найдет удаленные устройства и установит нужные драйвера. У устройств при этом не должно уже быть значка предупреждения о неработоспособности.
Все, после этого vpn должен начать подключаться без проблем. Возможно в каких-то случаях после всей этой процедуры нужно перезагрузить компьютер. Проблема у меня возникла на Windows 8.1 x64.
На одном из доменных компьютеров с Windows 7 столкнулся с проблемой - не применялась групповая политика компьютера, при этом в системном журнале компьютера регистрировалось событие с номером 1055:
Ошибка при обработке групповой политики. Не удалось разрешить имя компьютера. Возможные причины:
a) Ошибка разрешения имен на текущем контроллере домена.
b) Запаздывание репликации Active Directory (созданная на другом контроллере домена учетная запись еще не реплицирована на текущий контроллер домена).
При этом в Подробностях можно было видеть следующий дополнительный код ошибки:
ErrorCode 1331
ErrorDescription Вход в систему не произведен: учетная запись в настоящее время отключена.
На Технете существует статья по событию 1055, однако по ErrorCode 1331 там нет никакой информации. Имена на контроллере домена разрешались нормально, dcdiag никаких ошибок не показывал, с репликацией проблем не было, sysvol была доступна с проблемного компа, учетная запись компьютера конечно же была включена. При генерации Результирующей политики (RSoP) выдавалась следующая ошибка:
Инфраструктура групповой политики не удалось выполнить из-за указанной ниже ошибки.
Вход в систему не произведен: учетная запись в настоящее время отключена.
Примечание: из-за ошибки ядра групповой политики никакие другие компоненты групповой политики не выполнили обработку своей политики. Тем самым, информация о состоянии других компонентов недоступна.
В результате долгих раздумий и исканий выяснилось следующее - на компьютере под аккаунтом Локальная система (Local System аccount) были закэшированы реквизиты сторонней учетки для доступа к контроллеру домена. А именно от имени этого аккаунта идет обращение к КД для получения групповых политик компьютера. Т.е. при попытке получить групповые политики с контроллера домена обращение к нему шло от этой закэшированной учетки, которая действительно была отключена. Проблема решилась после удаления этой учетки из кэша, сделать это можно следующим образом:
1) С Технета качаем всем известный пакет Sysinternals PSTools, из него нам потребуется утилита PsExec 2) Запускаем командную строку от имени администратора и выполняем в ней PsExec.exe -i -s cmd.exe, в результате запустится командная строка под системной учетной записью 3) В этой командной строке запускаем rundll32.exe keymgr.dll, KRShowKeyMgr, в результате откроется окно "Сохранение имен пользователей и паролей", в котором можно увидеть все закэшированные учетки под системной учетной записью:
4) Удаляем ненужные учетки. Прежде всего нужно обратить внимание на те, которые используются для авторизации на КД. В моем случае тут была только одна учетка. 5) Перезагружаем компьютер, проверяем, как отработалась политика компьютера, и наслаждаемся жизнью
При изменении пути перенаправленной папки через групповые политики на новый путь, при этом когда сами данные физически продолжают оставаться в том же самом месте (например, в случае использования нового пути DFS или кластера), можно столкнуться с тем, что все файлы из папки будут удалены. Это может произойти тогда, когда в настройках перенаправления папки включен параметр "Move contents of ... to the new location" (Перенести содержимое ... в новое местоположение). Конечным действием операции переноса является удаление файлов из начального местоположения, но так как физически оно одно и тоже, происходит полное удаление всех файлов из перенаправленной папки. Будьте внимательны в таких случаях! Не забывайте снимать указанную галку в настройках перенаправления папки, либо включите параметр групповой политики "Verify old and new Folder Redirection targets point to the same share before redirecting" (Проверить перед перенаправлением, указывают ли старый и новый конечный объект перенаправления папки на один общий ресурс). Этот параметр находится в Computer Configuration/Polices/Administrative templates/Windows Components/Windows Explorer. При включении этой политики, Windows перед переносом файлов определяет путем записи временного файла - в одно и то же физическое место хранения происходит перенаправление или нет. В случае обнаружения, что папка перемещается в одно и то же место, происходит только изменение пути без операции копирования и удаления файлов.
При использовании перенаправленных папок (redirected folders) на компьютерах с Windows 7, 8, Vista на сетевые ресурсы DFS с включенным использованием Автономных файлов (Offline files) столкнулся со следующей проблемой - при попытке синхронизировать автономные файлы через Центр синхронизации операция зависает в статусе "Синхронизация ожидается" (Sync pending) и так никогда и не происходит. После изучения сайтов Microsoft с рекомендациями по настройке Автономных файлов и обзора зарубежного опыта отыскал таки проблему - для корректной работы синхронизации при использовании DFS в силу особенностей работы кэширования возможность использования Автономных файлов должна быть включена не только на уровне непосредственно Конечного объекта папки (Folder target), но и на уровне корня DFS. В настройках автономного режима сетевой папки, которая является корнем DFS, по крайней мере должно быть указано "Вне сети доступны только указанные пользователем файлы и программы". Далее уже на уровне Конечного объекта папки (Folder target) вы можете указывать, какие из них могут быть доступны автономно, а какие нет, в зависимости от вашей необходимости.
В моем случае указанный корень DFS использовался для хранения перемещаемых профилей пользователей и перенаправленных папок Мои документы и Рабочий стол. Пути имели следующий вид:
\\domain.local\data\profiles\ - тут хранились профили пользователей, для Folder target "profiles" использование автономных файлов отключено \\domain.local\data\userdata\ - тут хранились перенаправленные папки пользователей, для Folder target "userdata" автономные фалы были включены принудительно
На корне DFS "data" - автономные файлы были выключены принудительно. В итоге синхронизация через Центр синхронизация зависала в бесконечном "Синхронизация ожидается". Установка возможности кэширования на уровне корня решило проблему, при этом папка profiles не кэшируется, так как на ее уровне автономные файлы выключены.
Как известно, Microsoft поменяла принцип и технологию кэширования автономных файлов начиная с Windows Vista. В Windows XP кэш автономных файлов можно было сбросить в настройках автономных файлов путем клика на кнопку "Удалить файлы...", удерживая при этом SHIFT+CTRL. В результате появлялось окно с предложением инициализировать кэш и после перезагрузки кэш благополучно инициализировался:
В Windows Vista, Windows 7 (и скорее всего также и в Windows 8, не проверял) таким образом очистить кэш автономных файлов уже не получится. Для сброса кэша в указанных операционных системах нужно проделать следующее:
1) Запустить regedit и найти ветку HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\CSC\Parameters 2) Создать в этой ветке параметр DWORD (32 бита) с именем FormatDatabase и значением 1. 3) Перезагрузить компьютер.
ВНИМАНИЕ!!! Перед созданием параметра и инициализацией кэша обязательно убедитесь, что автономные файлы синхронизированы с соответствующими сетевыми папками - не синхронизированные изменения будут потеряны и вы можете лишиться важных данных!
После перезагрузки компьютера кэш будет переинициализирован и ключ автоматически удалён.
Можно создать параметр автоматически через командную строку, выполнив следующую команду:
Если вы используете аутентификацию в системе Windows на основе токенов Rutoken (или других токенов или смарткарт), например, для авторизации доступа к компьютеру, терминальному серверу (в общем, для авторизации входа в Windows), и на некоторых компьютерах она вдруг перестала работать и в окне аутентификации (Безопасность Windows) выдается ошибка "На этой смарт-карте не найдены действительные сертификаты" или "Действительные сертификаты не обнаружены", то возможно причина состоит в том, что на этот компьютер установили какое-либо стороннее криптографическое ПО, которое также может использоваться для авторизации входа в Windows, например, КриптоПРО CSP. Для решения проблемы необходимо отключить в этом стороннем криптографическом ПО поддержку авторизации входа в Windows. В случае КриптоПРО запустите оснастку КриптоПРО CSP, откройте вкладку Оборудование, далее Настроить типы носителей. В открывшемся окне найдите ваш тип носителя, в нашем случае это Rutoken, выберите его и нажмите Свойства. В открывшемся окне перейдите на вкладку Настройки и снимите галку "Для входа в Windows при помощи Rutoken использовать КриптоПРО CSP". После этого все снова начнет замечательно работать.
Зачастую при отключении устройства из компьютера, например сетевого адаптера, информация о нем остается в системе, и в дальнейшем при подключении нового аналогичного устройства ему присваивается индекс #2, #3 и т.д. При попытке присвоить новому сетевому адаптеру тот же ip-адрес, что и был на старом извлеченном из компьютера сетевом адаптере, выдается ошибка, что этот ip-адрес уже используется другим сетевым адаптером. Чтобы удалить такое отключенное и не отображающееся в системе устройство, нужно сделать следующее: 1) Запустить командную строку командой cmd 2) В командной строке выполнить команду set devmgr_show_nonpresent_devices=1 3) затем start devmgmt.msc и запустить Диспетчер устройств 4) В Диспетчере устройств в меню Вид поставить галку Показать скрытые устройства 5) Раскрыть нужную ветку, найти отсутсвующее устройство (оно будет затемненным) и удалить его. Ссылка на базу знаний Microsoft с описанием подобной проблемы http://support.microsoft.com/kb/269155