Ошибка теневого доступа неправильное имя компьютера
Обновлено: 06.07.2024
В Windows 2012 R2 и Windows 8.1 Microsoft вернула функционал Remote Desktop Shadowing (теневого подключения). Напомним, что режим Shadow (теневой сеанс) – может использовать администратором для просмотра и управления существующей RDP сессией любого пользователя. Этот режим работы поддерживается практически с первых версий терминального сервера Microsoft и неожиданно был убран в Windows Server 2012 (связано с переносом стека rdp из режима ядра в пользовательский режим). Функционал RDS Shadow работает и в следующих версиях ОС: Windows Server 2016 / Windows 10.Содержание:
Кроме того, у режима теневого подключения RDS Shadow и RDP клиента появился ряд новых интересных возможностей. Полный список параметров RDPклиента mstsc.exe, определяющих возможность удаленного теневого подключения к сессии конечного пользователя:
Mstsc.exe [/shadow:sessionID [/v:Servername] [/control] [/noConsentPrompt]]
/shadow:ID – подключится к RDP сессии с указанным ID.
/v:servername – имяRDP/RDS терминального сервера (если не задано, используется текущий).
/control – возможность взаимодействия с сеансом пользователя (если не указано, используется режим просмотра сессии пользователя).
/noConsentPrompt – не запрашивать у пользователя подтверждение на подключение к сессии.
/prompt –используется для подключения под другими учетными данными. Запрашивается имя и пароль пользователя для подключения к удаленному компьютеру.
Ограничения теневых сеансов RDS в Windows 2012 R2
Подключаться к чужим сессиям может только администратор сервера. Делегировать эти права обычным пользователем нельзяRDSShadowне будет работать в сетях на базе рабочих групп
Использование Remote Desktop Shadow из графического GUI
Подключиться к сессии пользователя можно с помощью утилиты mstsc.exe или непосредственно из консоли Server Manager. Для этого в консоли Server Manager откройте коллекцию QuickSessionCollection
Щелкнув по сессии интересующего пользователя, выберите в контекстном меню Shadow (Теневая копия).
Появится окно параметров теневого подключения. Возможен просмотр (View) и управление (Control) сессией. Кроме того, можно включить опцию Prompt for user consent (Запрашивать согласие пользователя на подключение к сессии).
Если выбрана опция «Запрашивать согласие пользователя», в сессии у пользователя появится запрос:Запрос на удаленное наблюдение
Winitpro\administrator запрашивает удаленный просмотр вашего сеанса. Вы принимаете этот запрос.Winitpro\administrator is requesting to view your session remotely. Do you accept the request?
Если пользователь подтвердит, подключение, в режиме просмотра администратор увидит его рабочий стол, но не сможет взаимодействовать с ним.Совет. Для отключения от сессии пользователя и выхода из shadow-режима нужно нажать ALT+* на рабочей станции или Ctrl+* на терминальном сервере (если не заданы альтернативные комбинации).
Если же пользователь отклонит подключение, появится окно:Shadow Error: The operator or administrator has refused the request
Если попытаться подключиться к сессии пользователя без запроса подтверждения, появится ошибка, сообщающая, что такое это запрещено групповой политикой:Shadow Error: The Group Policy setting is configured to require the user’s consent. Verify the configuration of the policy settings.
Параметры удаленного управлениями RDS сессиями пользователя настраиваются политикой Set rules for remote control of Remote Desktop Services user sessions (Установить правила удаленного управления для пользовательских сеансов служб удаленных рабочих столов), которая находится в разделе Policies -> Administrative Templates -> Windows components -> Remote Desktop Services -> Remote Session Host -> Connections (Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Подключения) в пользовательской и «компьютерной» секциях GPO. Данной политике соответствует dword параметр реестра Shadow в ветке HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.
Этой политикой можно настроить следующие варианты теневого подключения через теневое подключение RD Shadow::
- No remote contol allowed — удаленное управление не разрешено (значение ключа реестра Shadow = 0);
- Full Control with users’s permission — полный контроль с разрешения пользователя (1);
- Full Control without users’s permission — полный контроль без разрешения пользователя (2);
- View Session with users’s permission – наблюдение за сеансом с разрешением пользователя (3);
- View Session without users’s permission – наблюдение за сеансом без разрешения пользователя (4).
Теневое подключение RDS Shadow из PowerShell
Воспользоваться функционалом теневого подключения к сессии пользователя через теневое подключение Remote Desktop Services можно и из Powershell.
В первую очередь покажем, как получить список сессий на терминальном сервере (сессии пользователей будут сгруппированы в группы в зависимости от их статуса):
На данном сервере мы обнаружили три активных терминальных сессии. Подключимся к сессии пользователя с ID сессии 3:
Mstsc /shadow:3 /control
Также для получения списка всех сессии на сервере можно выполнить команду
На экране отобразится список RDP сессий, их ID и статус: активная сесиия (Active) или отключенная (Disconnected).
Для получения списка сессий на удалённом сервере выполните команду:
query session /server:servername
Для более удобного теневого подключения к сессиям можно использовать следующий скрипт. Скрипт предложит ввести имя удаленного компьютера и выведет список всех сеансов и предложит указать сеанс, к которому нужно подключится:
shadow.bat
@echo off
set /P rcomp="Enter name or IP of a Remote PC: "
query session /server:%rcomp%
set /P rid="Enter RDP user ID: "
start mstsc /shadow:%rid% /v:%rcomp% /control
Можно поместить данный файл в каталог %Windir%\System32, в результате для теневого подключения достаточно выполнить команду shadow.
Для подключения к консольной сессии можно использовать такой скрипт:
Как разрешить обычном пользователям использовать теневое подключение
В рассмотренных выше примерах для использования теневого подключения к терминальным сессиям необходимы права локального администратора на RDS сервере. Однако можно разрешить использовать теневое (shadow) подключение для подключения к сессиям пользователей и простым пользователям (не давая им прав локального администратора на сервере).
К примеру, вы хотите разрешить членам группы AllowRDSShadow использовать теневое подключение к сессиям пользователей, выполните команду:
wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName='RDP-Tcp') CALL AddAccount 'corp\AllowRDSShadow',2
Вы используете Internet Explorer устаревшей и не поддерживаемой более версии. Чтобы не было проблем с отображением сайтов или форумов обновите его до версии 7.0 или более новой. Ещё лучше - поставьте браузер Opera или Mozilla Firefox.
Обсудить и задать вопросы можно в этой теме.
Валентин_НН
литератор
координатор
В.Н.> взял-таки себе такой монитор
В.Н.> ну так. прикольно. ярко только очень
Не угодишь вам.. Из отзывов по твоей ссылке:
старожил
В.Н.>> ну так. прикольно. ярко только оченьНадеюсь, ты скриншот разместил не для того, чтобы мы яркость твоего монитора оценили?
Валентин_НН
литератор
Bod> Не угодишь вам.. Из отзывов по твоей ссылке:
ну уж хз. сейчас яркость поставил на тридцать процентов и мне норм.
Валентин_НН
литератор
GOGI> А исключительно оценить твои извращенные пристрастия по поводу ориентации монитора?
первый раз работаю с таким большим разрешением. прям дофига всего влезает на экран. непривычно.
В мониторе есть встроенные колонки. и датчик присутствия пользователя. Отходишь - монитор гаснет. и начинает усиленно экономить электричество. Фигово только, что и звук вырубается
пс.но если вместо себя оставить кружку, система не срабатывает.
ппс. но срабатывает жена - ты чего кружки за собой не убираешь?
блин косой с этой автоматизацией
Bredonosec
аксакал
вопрос возник.
Есть утиль под вынь. RDP Wrapper
Снимает ограничения обычных несерверных версий выни на только один сеанс в одно время. По дефолту можно настраивать до 15 сеансов, и, что самое главно, подключаться к активному сеансу удаленно, не выбивая локального юзера из него.
Условно "не-запретный", бо она всего навсего кидает на диск свою длл-ку и в реестре путь к терм.серверу переписывает на свою длл-ку вместо виндовой termsrv.dll
Собсно вопрос такой:
На машинвах вне домена - всё пашет отлично.
На машинах в домене - почему-то можно всё кроме того, что мне надо - подключения вдвоем к одному сеансу.
Можно сидеть под разными юзерами одновременно. Можно даже одному юзеру открыть несколько сеансов, если снять галку single session per user. Но вот вместе один сеанс - хрен. Выбрасывает локального при подключении удаленного хоть убейся веником.
Была мысль, что в политиках что-то накосячено, но сколько искал, ничего не нашел.
Куда тут еще можно копать?
ЗЫ всякие тимвьюеры-vnc-радмины и прочее нелегальное не надо предлагать, запрещено. remote assistance тоже нихрена не то, что нужно, бо не работает так, как мне надо. Интересует решение именно в рамках вопроса
e_maksimov
втянувшийся
Bredonosec> она всего навсего кидает на диск свою длл-ку и в реестре путь к терм.серверу переписывает на свою длл-ку вместо виндовой termsrv.dllНаверняка эта та же MS'овская DLL, только или пропатченная по примеру DLL из беты или вообще родная из беты без каких-то изменений. Нарушение лицензионного соглашения
Bredonosec> Была мысль, что в политиках что-то накосячено, но сколько искал, ничего не нашел.
Если DLL на базе MS'овской из беты, то она будет смотреть политику "Административные шаблоны" -> "Компоненты Windows" -> "Службы терминалов" -> "Ограничить пользователей службы терминалов одним удаленным сеансом", а если эта политика не задана, то смотрятся настройки службы терминалов. Только я ХЗ, DLL из беты видит доменные или только локальные политики/настройки, этот момент не копал.
Bredonosec
аксакал
e.m.> Наверняка эта та же MS'овская DLL, только или пропатченная по примеру DLL из беты или вообще родная из беты без каких-то изменений. Нарушение лицензионного соглашения
ну.. формально да.. но по факту я всё равно один буду юзать, мне просто важно, чтоб на том компе экран показывал в точности то же самое, что и я делаю удаленно, не выкидывая.
e.m.> Если DLL на базе MS'овской из беты, то она будет смотреть политику "Административные шаблоны" -> "Компоненты Windows" -> "Службы терминалов" -> "Ограничить пользователей службы терминалов одним удаленным сеансом",
спасибо )
Вообще-то
Local PC policies -> admin templates -> windows components -> Remote desktop services -> RDP session host -> limit number of connections
Но всё равно не задано. Ни это, ни каких-либо слов о том, что нужно мне: удаленное подключение к той же активной сессии консоли. Теперь хоть уверен в том
>а если эта политика не задана, то смотрятся настройки службы терминалов.
копаю щас RDP session host config tool с настройкой limit monitors per session.. походу оснастку сначала надо установить.
e_maksimov
втянувшийся
Bredonosec> Вообще-то
По старой версии винды смотрел, другой нет сейчас под рукой.
Bredonosec> Ни это, ни каких-либо слов о том, что нужно мне: удаленное подключение к той же активной сессии консоли
А, так еще и Remote Desktop Shadowing требуется? Тогда хочется подробностей про ОС и как подключаешься.
В принципе, патченная DLL для этого не требуется на сравнительно новых виндах:
Теневое RDP подключение к рабочему столу пользователя в Windows 10 | Windows для системных администраторов
Bredonosec
аксакал
e.m.> А, так еще и Remote Desktop Shadowing требуется? Тогда хочется подробностей про ОС и как подключаешься.
В принципе, не "еще", а только она Я просто не знал этого термина )
e.m.> В принципе, патченная DLL для этого не требуется на сравнительно новых виндах:
e.m.> Теневое RDP подключение к рабочему столу пользователя в Windows 10 | Windows для системных администраторов
Спасибо за наводку, материал по виду то, что мне и надо, но!
Но при попытке отработать на 2 машинах с вин7 и в домене, даже несмотря на установку указанных обнов (на обе, несмотря на то,что они говорили, что уже установлены), и выставление в реестре RPC на 1 и термсервис на 2 (без спроса) - всё равно шиш. Тупо "имя компьютера неправильное".
Что по имени, что по ИПу. Пробовал еще два бэкслеша добавлять в начале - без разницы, реакция идентична.
При попытке qwinsta на тему вывода сессий - ошибка 1722.
Что им еще может не хватать тогда?
e_maksimov
втянувшийся
Bredonosec> Что им еще может не хватать тогда?К сожалению точно,не подскажу, на 7-ке сам shadow не пользовал, могу посмотреть на выходных. RPC-порты не закрыты, случайно, файрволлом?
Bredonosec
аксакал
e.m.> К сожалению точно,не подскажу, на 7-ке сам shadow не пользовал, могу посмотреть на выходных. RPC-порты не закрыты, случайно, файрволлом?хм.. гугланул, там вроде конкретных не указано..
На рдп 3389 так точно открыты, сам проверял наличие..
А проверить дома не могу, это всё на работе, я туда до понедельника не попаду..
Поигрался бы и на 10, но под рукой были только машины с 7..
e_maksimov
втянувшийся
Bredonosec> На рдп 3389 так точно открытыRPC на Windows, ЕМНИП, это 135.
e_maksimov
втянувшийся
Проверил на 7-ке, обобщаю:
Использовать shadow-подключение к пользовательскому сеансу возможно двумя способами: локально и удаленно, при любом из них требуется задать разрешение на подключение к сеансу пользователя через реестр или групповые политики, иначе при попытке использовать shadow в доступе будет отказано.
Локальное использование shadow: зайти в отдельный сеанс на сервере, локально на консоли компьютера или удаленно по RDP-протоколу (версия RDP-протокола не важна) и уже внутри открытой сессии подключиться для управления к сессии другого пользователя через консольную команду shadow, либо через "Менеджер Задач" или RDC Manger. При включенном UAC потребуется запуск от администратора, но при подключении через "Менеджер Задач" достаточно сначала подтвердить запрос UAC включив "Отображать процессы всех пользователей" во вкладке "Процессы". Этот способ накладывает ограничения на ОС выступающую в роли сервера - она должна позволять держать активными минимум две сессии. XP/Vista/7/8 это не позволят без мухлежа (патч на DLL или замена на DLL из беты, либо использование RDP Wrapper Library - он не патчит, но все равно нарушает лицензионную политику и поддерживает минимум 7-ку).
Bredonosec
аксакал
e.m.> Локальное использование shadow: зайти в отдельный сеанс на сервере, локально на консоли компьютера или удаленно по RDP-протоколу (версия RDP-протокола не важна) и уже внутри открытой сессии подключиться для управления к сессии другого пользователя через консольную команду shadow, либо через "Менеджер Задач" или RDC Manger.
ээ. не имею на чем опробовать (комп с семеркой рендерит видео, не хочу трогать), это в таскманажоре на сессию другого юзера ткнуть просто? И переключит, или откроет в отдельном окне вторую?
e.m.> требуется установить апдейты из KB2830477,
Так всё это было по ссылке, что ты дал, и по ссылкам из неё же. я всё это сделал, написал вчера.
Единственное, что порты 445 не проверил, проверю в понедельник.
e_maksimov
втянувшийся
Bredonosec> в таскманажоре на сессию другого юзера ткнуть просто?
Да. Правой кнопкой мыши на нужную сессию и выбрать "Удаленное управление", при подключении будет выбором хоткея выхода обратно в RDP-сеанс. По-умолчанию, хоткей Ctrl + * на цифровом блоке. Значение хоткей по-умолчанию меняется в реестре машины к которой осуществляется теневое подключение, за это отвечает ветка "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\TaskManager" или "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSADMIN", в ключах "ShadowHotkeyKey" и "ShadowHotkeyShift" указываются в dword порядковые номера записей в выпадающем списке доступных хоткей. Хоткей Ctrl + * действует и при подключении через shadow, причем для shadow нет возможности его изменить через параметры запуска и на 7-ке указанные ключи реестра на хоткей для shadow у меня не повлияли.
Bredonosec> переключит, или откроет в отдельном окне вторую?
Переключит, переведя RDP-сеанс из которого подключился в тип "Теневой", если в теневом подключении нажать хоткей, то вернется обратно в RDP-сеанс.
Bredonosec> по ссылкам из неё же. я всё это сделал,
Так другие тоже могут читать
С консольным shadow все еще забавнее, оказывается. Shadow может подключать любой терминальный сеанс к сессии пользователя, даже если запускать shadow из под терминальной сессии на другом компе в сети. Только shadow не умеет самостоятельно авторизоваться и использует авторизацию клиента сети Майкрософт, поэтому нужна возможность установления между пользовательской и терминальной сессией сетевого сеанса с авторизацией под логином пользователя, в чей сеанс нам надо подключиться, либо под записью имеющей на целевом компьютере права администратора. То есть, терминальный сеанс на клиентской машине вообще не требуется и можно подключаться в теневом режиме к XP/Viste/7-ке без мухлежа с DLL и RDP Wrapper Library, только в цепочку подключений потребуется добавить еще один комп, поскольку к локальному консольному сеансу shadow не умеет подключать сеанс с удаленного компьютера, а через терминальный сервер не создает сеанс на том же компьютере, с которого запускаешь терминальный клиент (по крайней мере по-умолчанию, но этот момент не копал). Несколько путано, но на примере будет понятнее, надеюсь.
Допустим, у нас есть еще три компа: Initiator, Proxy и Target. На Target в локальном сеансе сидит пользователь с логином User и нам надо подключиться к его сеансу в теневом режиме. Этот User имеет на Target права обычного пользователя и даже не входит в группу "Remote Desktop Users". На Proxy есть какой-то пользователь входящий в группу "Remote Desktop Users", админские права ему так же не требуются. Мы сидим на Initiator, пофиг какая у нас ОС, хоть Android на смартфоне, мы можем находиться за пределами основной сети и не видеть Target, но нам нужна возможность подключиться по RDP к Proxy (версия протокола роли не играет). Proxy должен видеть ресурсы SMB на Target, т.е. на Proxy и Target должна работать сеть Майкрософт с возможностью авторизации ("общий доступ к файлам и принтерам" и "доступ по паролю" в случае рабочей группы). Так же на Target должны быть открыты соответствующие порты, присутствовать сетевые ресурсы IPC$, ADMIN$ и C$ (или иная буква системного раздела), а так же, в некоторых случаях понадобится вспомогательная шара доступная пользователю User.
Шаг 1. Подключаемся по RDP с Initiator на Proxy и входим под какой-то учеткой. Учетку с правами админа, даже локального для Proxy, не рассматриваем - это скучно и небезопасно, поэтому возможны два варианта, но оба требуют знания пароля от User:
а) У нас домен, User доменный пользователь и мы вошли на Proxy под ним - это самый простой вариант, в этом случае с Proxy сразу доступны специальные ресурсы Target. Идем в консоль, набираем "qwinsta User /server:Target" и видим ID сеанса под которым сидит этот юзер на Target. Далее набираем "shadow ID /server:Target" и подключаемся к этому сеансу в теневом режиме. Выходим по хоткей.
б) У нас рабочая группа, либо нам не хочется авторизоваться на Proxy под доменной учеткой и мы авторизуемся под локальным пользователем Proxy. Далее идем в Проводник (либо в консоли используем возможности команды "net") и пытаемся войти на Target в шару C$ (если User является админом на Target) или в отдельную шару с доступом для User. В поле авторизации вводим имя пользователя вместе с именем его компьютера (Target\User) или домена (Domain\User), в зависимости от принадлежности учетки и пароль. Если поставить галку "сохранить пароль", то можно будет попасть в засаду при попытке подключиться через Proxy к сеансу другого пользователя на Target и придется удалять пароль User из сохраненных через оснастку хранилища паролей. Далее аналогично: узнаем ID сеанса "qwinsta User /server:Target", подключаемся "shadow ID /server:Target", выходим по хоткей.
Если групповой политикой включен режим доступа не запрашивающий подтверждения на управление, то у пользователя на Target лишь быстро моргнет экран. В Диспетчере Задач не появится новых сеансов и если мы себя никак не проявим или подключаемся в режиме просмотра, то пользователь даже не узнает о нашем подключении. Узнать он сможет только если ему хватит прав на запуск оснастки "Общие файлы", где в списке открытых файлов будут записи типа "LSM_API_service", "Shadowpipe" и "TermSrv_API_service" под именем пользователя которым мы авторизовались на Proxy по SMB. Либо в tcpview из набора Sysinternals, там будет видно входящее подключение с Proxy на порт TCP 445 (microsoft-ds), а если у пользователя хватит прав, то и растущие показания счетчика пакетов у этого соединения.
В теории, подключение по RPC должно отличаться от RDP-подключения по загрузке процессора на Target и утилизации полосы от Target до Proxy, но я не смог увидеть разницы на виртуалках.
Удаленному рабочему столу не удалось найти компьютер %PCName%". Это может означать, что %PCName% не принадлежит указанной сети. Проверьте имя и домен компьютера, к которому выполняется подключение.
Remote Desktop Can’t Find the computer %PCName%. This might mean that %PCName% does not belong to the specified network. Verify the computer name and domain that you are trying to connect to.
В большинстве случае эта ошибка свидетельствует о том, что имеются проблемы с вашим DNS сервером, из-за которых ваш компьютер не может отрезолвить указанное имя.
В первую очередь убедитесь, что вы правильно указали имя удалённого RDP хоста в клиенте RDP в поле Компьютер .
Попробуйте подключиться к RDP серверу по IP адресу вместо DNS имени.
Затем попробуйте выяснить, знает ли ваш DNS сервер FQDN имя RDP сервера, к которому вы подключаетесь (%rdpserver%). Откройте командную строку с правами администратора и выполните команду:
Убедитесь, что команда вернула IP адрес сервера, например:
В том случае, если команда вернула некорректную запись, попробуйте на клиенте сбросить кэш DNS ( ipconfig /flushdns ) и разрешить имя вашего RDP сервера с помощью nslookup еще раз.
В том случае, если команда Nslookup по прежнему возвращает неверную запись, откройте файл hosts комадой:
В том случае, если в файле отсутствуют статические записи для вашего RDP сервера (это, в общем-то, правильно), вы можете попробовать добавить их вручную (тем самым вы сможете обойти некорректные записи, которые возвращает ваш DNS сервер). Нужно добавить строку формата:
Проверьте доступность RDP сервера с помощью команды ping:
Затем следует проверить, что с клиента на сервере доступен RDP порт 3389 (это порт для RDP подключения по-умолчанию). Проще всего проверить доступность порта с помощью PowerShell команды:
Test-NetConnection rdpserver -port 3389
В том случае, если команда Test-NetConnection вернула TcpTestSucceeded : False, это означает что RDP служба на удаленном компьютере не включена, либо подключение блокируется файерволом на стороне клиента, сервера или на межсетевых экранах или маршрутизаторах между ними.
Несколько советов, которые стоит проверить, при невозможности подключиться к удаленному RDP хосту:
Данные цифры говорят нам о том, что сбой произошел из-за некорректного функционирования компонента, отвечающего за теневое копирование (VSS). Эта технология позволяет взаимодействовать с любыми файлами, в том числе и заблокированными системными или сторонними процессами. Кроме того, такой код может появиться при попытке использования точек восстановления. Причин, вызывающих ошибку, несколько. Это могут быть проблемы как в настройках ОС, так и в жестком диске. С него и начнем.
Причина 1: Системный диск
Все бэкапы (точки восстановления) по умолчанию записываются на системный жесткий диск, обычно имеющий букву «С». Первый фактор, который может повлиять на нормальное течение операции, это банальная нехватка свободного пространства. Проблемы начинаются (не только с теневым копированием) тогда, когда от объема остается менее 10%. Чтобы это проверить, достаточно открыть папку «Компьютер» и посмотреть на полосу загрузки раздела.
Если места мало, нужно очистить диск по инструкции, приведенной ниже. Можно также удалить и лишние файлы из системных папок.
Фактор, влияющий на сбои при восстановлении – «битые» сектора на диске. Их можно выявить, применив рекомендации, представленные в статье ниже. Если в качестве системного используется SSD, для таких накопителей также имеются инструменты для проверки здоровья. При обнаружении ошибок «железка» подлежит скорейшей замене с переносом данных и системы на другой диск.
Причина 2: Антивирус и брандмауэр
Программы, которые призваны защитить нас от вирусов и сетевых атак, могут препятствовать нормальной работе некоторых компонентов системы. Для исключения этого фактора нужно на время отключить антивирус и брандмауэр, причем это касается как стороннего софта, так и встроенного в систему.
Причина 3: Службы
-
Вызываем меню «Пуск», в поисковое поле вводим «Службы» без кавычек и открываем указанный на скриншоте раздел.
В некоторых случаях изменить параметры службы через графический интерфейс невозможно. Здесь поможет такой инструмент, как «Командная строка», которая должна быть запущена от имени администратора.
По очереди вводим команды и нажимаем ENTER (после каждой).
sc stop vss
sc config vss start= auto
sc start vss
Примечание: после «start=» должен стоять пробел.
При повторении сбоя следует проверить зависимости службы. Эта информация указана на вкладке с соответствующим названием в окне свойств «Теневого копирования тома».
Ищем в списке каждый указанный сервис и проверяем его параметры. Значения должны быть такие: состояние «Работает», тип запуска «Автоматически».
Если параметры отличаются от указанных, придется поработать с системным реестром.
-
Узнаем имя службы. Его можно найти в окне свойств.
Кликаем по нему дважды, меняем значение на «2» и жмем ОК.
Если ошибка продолжает возникать, следует вернуть тип запуска для «Теневого копирования тома» на «Вручную» и остановить сервис.
В командной строке это делается так:
sc config vss start= demand
sc stop vss
Причина 4: Настройки групповых политик
Ошибка 0x80042302 может возникать по причине отключения восстановления системы в «Редакторе локальной групповой политики». Данная оснастка присутствует только в редакциях «Профессиональная», «Максимальная» и «Корпоративная». Как ее запустить, описано в статье ниже. Если ваша версия не позволяет воспользоваться этим инструментом, можно выполнить аналогичные действия в реестре.
-
В редакторе проходим по следующему пути:
«Конфигурация компьютера» - «Административные шаблоны» - «Система» - «Восстановление системы»
Справа кликаем дважды по позиции, указанной на скриншоте.
В редакторе реестра за данный параметр отвечает ключ
Находится он в ветке
Для него нужно задать значение «0» (двойной клик, меняем значение, ОК).
В этом разделе может присутствовать еще один ключ с названием
Для него нужно провести ту же процедуру. После всех действий следует перезагрузить ПК.
Мы рассмотрели четыре причины возникновения ошибки 0x80042302 в Windows 7. В большинстве случаев приведенных инструкций достаточно для их устранения. Если для вас не принципиально использование системного средства для бэкапа, можно посмотреть в сторону других инструментов.
Последним средством исправления будет переустановка системы.
Отблагодарите автора, поделитесь статьей в социальных сетях.
Читайте также: