Проблема в том что сдох главный КД, по вашим хэлпам предлагают удалит КД из леса, а можно не удаляя ? или как сделать так чтоб нерухнул домеен окончательно, по тому как с годика 2 назад у нас тоже полетел
КД но вывод его из домена привел к полной переустановке доменна со всеми вытикающими а именно переустановке всех серверов и пк (более 300) в сети.
Не удаляя — скорее всего, нельзя. Потому что учетная запись его исчезла, и воссоздать её вручную корректно очень сложно (я, например, возьмусь за это только в очень крайнем случае, и это будет долго и не без риска).
Далее, что такое «главный» КД? Если тот, на котором находятся роли FSMO, то эти роли — всего лишь записи в AD с именами КД, которые выполняют соответствующие функции. Их вполне можно переназначить на другой КД — и он
с тем же успехом будет их выполнять. В вашем случае, т.к. бывший владелец ролей недоступен, для переназначния необходимо использовать процедуру захвата роли (делается командой seize в ntdsutil, при необходимости дам
ссылку на полную инструкцию).
По всем этим процедурам есть один только один важный дополнительный совет, которого в инструкциях часто нет: если удаляемый КД является владельцем роли PDC emulator, то надо обязательно сохранить копию содержимого SYSVOL
(по умолчанию — папку C:\SYSVOL\domain): актуальное содержимое SYSVOL обычно находится именно на нем, и если репликация его на другие КД не работала, то его можно потерять, в результате вы потеряете содержимое политик.
Ну, и перед удалением неплохо было бы убедиться, что домен без удаленного КД функционирует: выключите его и посмотрите некоторое время, как все работает.
PS. Ну, а два года назад вы явно сделали что-то неправильное — в большинстве случае при отказе одного КД, если их несколько и они исправны, заново создавать домен не требуется. Может быть, у вас не было контроля за исправностью других КД?
PPS Исчезновение учетной записи КД — это очень странный случай. Его неплохо было бы расследовать. Потому что если не рассматривать катастрофические сценарии (повреждение базы AD, некорректное восстановление копии базы AD на другом КД),
сценариев, как это могло произойти случайно, мало. Мне на ум приходит единственный: в домен был введен, а впоследствии — переименован компьютер с тем же именем, что и у пострадавшего КД.
Слава России!
-
Помечено в качестве ответа
2 октября 2020 г. 14:13
Обновлено 28.03.2022
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз я вас научил делать резервные копии с помощью утилиты Robocopy, это было очень полезно. В сегодняшней заметке я покажу, как решается проблема с вылетевшим из домена компьютером, который при логине выводит ошибку «База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера«. Думаю, что многие с ней сталкивались, но не все ее решали и понимали откуда эта проблема берется.
Описание проблемы
Давайте я подробнее опишу рабочее окружение. И так есть лес Active Directory, в котором есть родительский домен, дочерний и транзитивный отдельный домен в рамках леса. Поступила задача мигрировать и доверительного домена объект компьютера в дочерний домен. Для этого была использована утилита ADMT 3.2. Сама миграция учетной записи компьютера прошла штатно. Далее я сменил принадлежность к домену Active Directory нового компьютера, у меня ввод был успешен, но было предупреждение, что якобы есть проблемы на уровне DNS-сервера. После перезагрузки и попытке на него залогиниться появилась вот такая ошибка:
База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станции
В английской версии, это выглядит вот так:
The security database on the server does not have a computer account for this workstation trust relationship
Как решить проблему с доверительными отношениями
И так давайте рассуждать, тут есть два сценария, когда вы можете увидеть эту ошибку:
- Во первых, это когда у вас компьютер или сервер не включались более 30 дней и не обращались к контроллеру домена, так как по умолчанию, каждые 30 дней все учетные записи компьютеров меняют свой пароль безопасности для канала между ними и контроллером домена
- Во вторых, это когда у вас на уровне леса есть два компьютера с одинаковыми именами, которые мешают друг другу и конфликтуют
Что делать в таких ситуациях, в первом случае, это сбросить учетную запись компьютера и восстановить безопасный канал, во втором случае найти дубли, удалить их и уже после этого заново восстанавливать канал между компьютером и контроллером домена.
В ситуации, когда компьютер по тем или иным причинам не мог связаться с контроллером домена, он не мог вовремя обновить свой пароль, в этом случае, когда он появится в локальной сети, он попытается аутентифицироваться со старым паролем в следствии чего будет успешно послан DC на все четыре стороны и получит ту самую ошибку «База данных диспетчера учетных записей на сервере не содержит записи»
Как это исправить. Вам потребуется знать и иметь административную, локальную учетную запись от имени которой вы будите проводить манипуляции по восстановлению доверительных отношений.Если же у вас нет доступа к этой учетной записи, то вам придется сбросить пароль администратора Windows. Далее имея административный, локальный доступ вам нужно сбросить безопасный канал, об этом я уже рассказывал в статье не удается установить доверительные отношения с доменом. Там вы выбираете любой удобный способ:
- Утилита Netdom
- Nltest
- Командлет Reset-ComputerMachinePassword
Если эти манипуляции не помогают, то у вас сто процентов конфликт имен на уровне леса. Первым делом я вам советую открыть логи на контроллере домена. Там вы со сто процентной уверенностью обнаружите ошибку с кодом ID 2974. Как видите в моем случае ошибка указывает на servicePrincipalName HOST/имя компьютера, именно из-за него конфликт.
Подробнее про ошибку ID 2974 вы можете почитать на сайте Microsoft https://docs.microsoft.com/ru-ru/windows-server/identity/ad-ds/manage/component-updates/spn-and-upn-uniqueness
В моем случае сообщение об ошибке «База данных диспетчера учетных записей на сервере не содержит записи», появлялось потому, что после миграции у меня на старом месте осталась прошлая учетная запись компьютера и в новом месте она же присутствовала, что приводило к дублированию. У новой учетной записи компьютера, была обнаружена такая вещью, у нее не проставлялся атрибут AD servicePrincipalName. Чтобы в этом удостовериться откройте редактор атрибутов Active Directory подключитесь к контексту именования по умолчанию и найдите свой объект компьютера. Перейдите в его свойства.
Тут вы видите, что атрибут servicePrincipalName пустой, и если вы попытаетесь его заполнить, то получите ошибку, пока не уберете дубль.
Думаю что все умеют искать компьютеры в Active directory, но то же самое можно сделать и другими методами.
Например, через оболочку центр администрирования Active Directory, выбрав там глобальный поиск и введя там нужное имя компьютера.
Можно так же и через командную строку, через утилиту dsquery * —filter servicePrincipalName=* —attr Name.
После того, как вы обнаружили ваш дублирующий компьютер в базе данных AD, то удаляем его. После этого, чтобы без перезагрузок и вывода и повторного ввода в домен, нового компьютера сделайте вот что. Находясь в свойствах учетной записи компьютера через ADSIEdit, зайдите внутрь свойства атрибута servicePrincipalName. Там вам нужно в ручном режиме создать записи:
- HOST/dns имя компьютера
- HOST/полное FQDN имя
- RestrictedKrbHost/dns имя компьютера
- RestrictedKrbHost/полное FQDN имя
- TERMSRV/dns имя компьютера
- TERMSRV/полное FQDN имя
После этих внесений, в идеале перезагрузить этот компьютер, но работать будет и без этого. Еще одно дополнение, если вы хотите увеличить период смены пароля у учетных записей компьютеров, то это можно сделать с помощью групповой политики, отредактировав текущую или создав новую. Я вам предлагаю вам отредактировать политику Default Domain Controllers Policy. Перейдите по пути:
Конфигурация компьютера-Политики-Конфигурация Windows-Параметры безопасности-Локальные политики-Параметры безопасности-Computer Configuration-> Windows Settings-> Security Settings-> Local Policies-> Security Options (Computer Configuration-Windows Settings-Security Settings-Local Policies-Security Options)
По умолчанию стоит значение 30, можете легко поменять, я например, установлю 90 дней.
Отключение режима проверки уникальности имени участника-пользователя и имя участника-службы
Бывают случаи, что по ряду причин нет возможности удалить дублирующий объект. Для таких сценариев компания Microsoft выпустила обновление для Windows Server 2012 R2 и выше, которое позволяет на контроллерах домена, управлять поведением обнаружения дубликатов.
С помощью этого обновления корпорация Майкрософт предоставляет переключатель уровня леса выключить или включить проверку на уникальность посредством атрибута dSHeuristics.
Ниже приведены поддерживаемые dSHeuristics значения.
- dSHeuristic = 1: AD DS позволяет добавлять имена участников-пользователя (UPN)
- dSHeuristic = 2: AD DS позволяет добавлять имена участников повторяющихся службы (SPN)
- dSHeuristic = 3: AD DS позволяет добавление повторяющихся имен SPN и UPN
- dSHeuristic = любое другое значение: службы AD DS применяет проверка уникальности имен SPN и UPN
ссылка на подробное описание данного обновления https://support.microsoft.com/ru-ru/help/3070083/duplicate-spn-check-on-windows-server-2012-r2-based-domain-controller
Ссылка на само обновление https://www.catalog.update.microsoft.com/Search.aspx?q=3070083
Ошибка the trust relationship between this workstation and the primary domain failed
Разновидностью ошибки «База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения» может выступать вот такое уведомление:
The trust relationship between this workstation and the primary domain failed
Тут то же сервер не может связаться с контроллером домена, если вы зайдете на него консольно, то в журнале событий вы можете обнаружить критическую ошибку:
ID 5776 NETLOGON: Failed to create/open file \system32\config\netlogon.ftl with the following error: There is not enough space on the disk.
Как видно Windows просто не смогла открыть файл netlogon.ftl, за который отвечает служба NETLOGON, которая так же участвует в авторизации пользователя в систему. /В системе мониторинга, я так же нашел провал по свободному дисковому пространству.
Что такое netlogon.ftl ?
И так Windows хранит список входа в разделе реестра DomainCache. В реестре, это путь:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DomainCache
Windows заполняет ключ реестра DomainCache из файла с именем C:\WINDOWS\system32\config\netlogon.ftl
Раздел реестра DomainCache обновляется из netlogon.ftl в процессе загрузки компьютера и всякий раз, когда устанавливается подключение к удаленному рабочему столу. Сам же файл netlogon.ftl заполняется из Active Directory службой netlogon. В AD есть раздел defaultNamingContext в контейнере System. Он заполняется из типов объектов TrustedDomain. Посмотреть, что будет заполнено из базы Active Directory можно командой:
Так, что если локальная система не сможет прочитать содержимое файла netlogon.ftl, то ошибка с доверительными отношениями вам обеспечена. Вот так вот просто решается ошибка с отсутствием в базе данных Active Directory учетной записи компьютера для регистрации. С вами был Иван Семин, автор и создатель компьютерного портала Pyatilistnik.org.
Версия ПО: JMS всех версий, MS CA
Токены: Любые
Проблема:
Нет связи между УЦ MSCA и контроллером домена. Обычно сопровождается ошибкой вида:
«База данных диспетчера учётных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией».
Причина:
Как и учётные записи пользователей, учётные записи компьютеров в домене имеют свой пароль. Пароль этот нужен для установления так называемых «доверительных отношений» между рабочей станцией и доменом. Пароли для компьютеров генерируются автоматически и также автоматически каждые 30 дней изменяются.
Домен хранит текущий пароль компьютера, а также предыдущий. Если пароль изменится дважды, то компьютер, использующий старый пароль, не сможет пройти проверку подлинности в домене и установить безопасное соединение. Рассинхронизация паролей может произойти по разным причинам, например, компьютер был восстановлен из резервной копии, на нём была произведена переустановка ОС или он просто был долгое время выключен. В результате при попытке входа в домен нам будет выдано сообщение о том, что не удаётся установить доверительные отношения с доменом.
Решение:
Для восстановления доверительных отношений существует несколько способов. Рассмотрим их все по порядку.
Способ первый
Открываем оснастку «Active Directory Users and Computers» и находим в ней нужный компьютер. Кликаем на нём правой клавишей мыши и в контекстном меню выбираем пункт «Reset Account». Затем заходим на компьютер под локальной учётной записью и заново вводим его в домен.
Примечание. Кое-где встречаются рекомендации по удалению компьютераиз домена и его повторного заведения. Это тоже работает, однако при этом компьютер получает новый SID и теряет членство в группах, что может привести к непредсказуемым последствиям.
Способ этот довольно громоздкий и небыстрый, т.к. требует перезагрузки, однако работает в 100% случаев.
Способ второй
Заходим на компьютер, которому требуется сбросить пароль, открываем командную консоль обязательно от имени администратора и вводим команду:
Netdom Resetpwd /Server:SRV1 /UserD:Administrator /PasswordD:*
где SRV1 — контролер домена, Administrator — административная учётная запись в домене. Дополнительно можно указать параметр /SecurePasswordPrompt, который указывает выводить запрос пароля в специальной форме.
В открывшемся окне вводим учётные данные пользователя и жмём OK. Пароль сброшен, и теперь можно зайти на компьютер под доменной учётной записью. Перезагрузка при этом не требуется.
Что интересно, в рекомендациях по использованию и в справке написано, что команду Netdom Resetpwd можно использовать только для сброса пароля на контролере домена, другие варианты использования не поддерживаются. Однако это не так, и команда также успешно сбрасывает пароль на рядовых серверах и рабочих станциях.
Ещё с помощью Netdom можно проверить наличие безопасного соединения с доменом:
Netdom Verify WKS1 /Domain:Contoso.com /UserO:Administrator /PasswordO:*
Или сбросить учётную запись компьютера:
Netdom Reset WKS1 /Domain:Contoso.com /UserO:Administrator /PasswordO:*
где WKS1 — рабочая станция, которой сбрасываем учётку.
Способ достаточно быстрый и действенный, однако есть одно «но»: по умолчанию утилита Netdom есть только на серверах с установленной ролью Active Directory Domain Services (AD DS). На клиентских машинах она доступна как часть пакета удалённого администрирования Remote Server Administration Tools (RSAT).
Способ третий
Ещё одна утилита командной строки — Nltest. На компьютере, который потерял доверие, выполняем следующие команды:
Nltest /query — проверить безопасное соединение с доменом;
Nltest /sc_reset:Contoso.com — сбросить учётную запись компьютера в домене;
Nltest /sc_change_pwd:Contoso.com — изменить пароль компьютера.
Самый быстрый и доступный способ, ведь утилита Nltest по умолчению есть на любой рабочей станции или сервере. Однако, в отличие от Netdom, в которой предусмотрен ввод учётных данных, Nltest работает в контексте запустившего её пользователя. Соответственно, зайдя на компьютер под локальной учётной записью и попытавшись выполнить команду, можем получить ошибку доступа.
Способ четвёртый
PowerShell тоже умеет сбрасывать пароль копьютера и восстанавливать безопасное соеднение с доменом. Для этого существует командлет Test-ComputerSecureChannel . Запущенный без параметров он выдаст состояние защищённого канала — True или False.
Для сброса учётной записи компьютера и защищённого канала можно использовать такую команду:
Test-ComputerSecureChannel -Server SRV1 -Credential Contoso\Administrator -Repair
где SRV1 — контролер домена (указывать не обязательно).
Для сброса пароля также можно также воспользоваться такой командой:
Reset-ComputerMachineChannel -Server SRV1 -Credential Contoso\Administrator
Способ быстрый и удобный, не требующий перезагрузки. Но и здесь есть свои особенности. Ключ -Credential впервые появился в PowerShell 3.0. Без этого параметра командлет, запущенный из-под локального пользователя, выдает ошибку доступа. Получается, что данный метод можно использовать только на Windows 8 и Server 2012, ведь для остальных ОС PowerShell 3.0 пока недоступен.
Как видите, способов восстановления доверительных отношений более чем достаточно. Однако если проблема приобретает постоянный характер, то проще подойти к её решению с другой стороны.
Изменение параметров смены пароля компьютера
Смена пароля в домене происходит следующим образом.
Каждые 30 дней рабочая станция отправляет ближайшему контролеру домена запрос на изменение пароля учётной записи компьютера. Контролер принимает запрос, пароль изменяется, а затем изменения передаются на все контролеры в домене при следующей репликации.
Некоторые параметры смены пароля можно изменять. Например, можно изменить временной интервал или совсем отключить смену паролей. Сделать это можно как для отдельных компьютеров, так и для групп.
Если настройки необходимо применить к группе компьютеров, то проще всего использовать групповую политику. Настройки, отвечающие за смену паролей, находятся в разделе Computer Configuration — Policies — Windows Settings — Security Settings — Local Policies — Security Options. Нас интересуют следующие параметры:
Disable machine account password change — отключает на локальной машине запрос на изменение пароля;
Maximum machine account password age — определяет максимальный срок действия пароля компьютера. Этот параметр определяет частоту, с которой член домена будет пытаться изменить пароль. По умолчанию срок составляет 30 дней, максимально можно задать 999 дней;
Refuse machine account password changes — запрещает изменение пароля на контролерах домена. Если этот параметр активировать, то контролеры будут отвергать запросы компьютеров на изменение пароля.
Для одиночной машины можно воспользоваться настройками реестра. Для этого в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters есть два параметра :
DisablePasswordChange — если равен 1, то запрос на обновление пароля компьютера отключен, 0 — включен.
MaximumPasswordAge — определяет максимальный срок действия пароля компьютера в днях. При желании можно задать более 1 миллиона дней !!!
И в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters, только у контролеров домена, параметр:
RefusePasswordChange — если равен 1, то запрещает контролеру домена принимать запрос на изменение пароля. Этот параметр надо задать на всех контролерах в домене.
Статья взята с ресурса windowsnotes.ru. Исходный вариант данной статьи находится по ссылке в нижней части.
I have a database in a local file that is used by a program. The program has limited functionality and I needed to run some quick queries. I installed SQL Server Management Studio Express 2005 (SSMSE), connected to the SQL Server instance, attached the database file, and ran the queries. Now the original program will no longer connect to the database. I receive the error:
Cannot open user default database. Login failed. Login failed for user ‘MyComputer\MyUserName’.
I’ve gone back into SSMSE and tried to set the default database. I’ve opened up Security, Logins, BUILTIN\Administrators and BUILTIN\Users. Under General, I have set the default database to the program’s database. Under User Mappings, I made sure the database is ticked and that db_datareader and db_datawriter are ticked.
The program uses the connection string:
Server=(local)\Instance; AttachDbFilename=C:\PathToDatabase\Database.mdf; Integrated Security=True; User Instance=True;
I know jack-all about database administration. What else am I missing?
asked Dec 16, 2011 at 1:21
This may not be answering your question specifically, but it may help others with similar issue caused by different problem
In my case the problem was my user is defaulted to a database which is not accessible for any reason (can be renamed, removed, corrupted or …)
To solve the issue just follow the following instruction
-
Try to login again on the login page there is other tabs select
«Connection Properties». -
under the tab locate «Connect to database» and select an existing database you have access to like tempdb or master
-
Once you are connected to the SQL Server Instance execute the below TSQL to assign the login a new default database.
Use master GO ALTER LOGIN [yourloginname] WITH DEFAULT_DATABASE = TempDB GO
Alternatively once you connected change your default database name to master via UI
Article taken from :
http://www.mytechmantra.com/LearnSQLServer/Fix-cannot-open-user-default-database-Login-failed-Login-failed-for-user-SQL-Server-Error/
answered Apr 18, 2016 at 23:56
KiarashKiarash
1,7012 gold badges16 silver badges20 bronze badges
1
This problem manifested for me when I took my default db offline. Next thing I know I couldn’t login. Switching to the Connection Properties tab and selecting the drop down to change the database I want to connect to also failed.
It let me in right away once I manually typed master as the db I wanted to connect to (on the Connection Properties tab).
answered Jul 6, 2017 at 18:07
Mike CheelMike Cheel
12.7k10 gold badges72 silver badges101 bronze badges
First, try to isolate your problem:
- Take a backup of the file! Some of the steps below can, apparently, in some circumstances cause the file to vanish.
- Are you sure you are connecting to the same instance through Management Studio as the program is?
- If possible, try to shut down the instance that you are not expecting to use.
- Set the user’s default database to master and try to make the program logon.
- Try to login as the user through Management Studio — since you have integrated security, you should open Management Studio as the program’s user.
- Are you using «User instances» — perhaps without knowing it? If so, this may be helpful: http://blogs.msdn.com/b/sqlexpress/archive/2006/11/22/connecting-to-sql-express-user-instances-in-management-studio.aspx
I haven’t worked much with files being attached in the way your program does — but you write that you attached the DB in the Management Studio as well. Have you tried detaching it there before running your program? Perhaps you are seeing the Management Studio and your program competing for exclusive access to the MDF-file?
EDIT: I added point 6 above — this is new in my own list of TODOs when troubleshooting this type of Login failed. But it does sound a lot like what you’re experiencing.
EDIT2: In the first edit, new item was added to the list. So the numbers in the comments doesn’t correspond with the numbers in the answer.
answered Dec 20, 2011 at 23:20
5
I finally figured this out, and my situation is different than every other I’ve read about tonight.
I had restored my database from a backup. I knew that there was a particular login user that I had been using, so I created that user in SSMS. However, there was already a user by that name under the database that had come in with the backup.
Since I had screwed around so much trying to fix this, I wasn’t able to delete the user under the DB easily. I deleted the database and restored again. Then:
- Delete the user under the Databases->[my database]->Users
- Create the user again in Security->Logins (not under your DB, although that probably works too.
- Go to the newly created user. Select properties. Then under User Mappings, tell it to make your database the default. Give it read and write access.
Summary: I had two users. One that came with the DB, and one that I had created. Remove the one that came with the DB and create your own.
answered Feb 20, 2015 at 4:32
DustinADustinA
4995 silver badges9 bronze badges
I’ve also had this same problem, it turned out that I was trying to access the built in membership classes (in a view), and that .Net was trying to create the database in the App_Data folder:
@Membership.GetUser().ProviderUserKey
This will trigger the system to try and create a database based in the built in membership system, which may not be the way your system is setup.
answered Jun 11, 2015 at 17:09
In my case I had to set «connect to any database» right path:
On your instance, go to Security , then to Logins.
Right Click on there, you will see properties and you should click on Securables.
There it give possibility to connect to any database.
David
1,1474 gold badges17 silver badges29 bronze badges
answered Mar 7, 2017 at 14:04
- Select Authentication as Windows Authentication when login.
- Then go to Security>Logins and select the created login.
- Right-click on properties and go to the default database settings.
- Select the required database and select OK.
answered Jul 26 at 19:17
«База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией»: 13 комментариев
-
Maximalist А где эта команда должна быть выполнена? На контроллере домена или же на самом проблемном ПК?
-
admin Автор записи
Т.к. мы указываем имя проблемной машины и имя контроллера домена то выполнена она может быть на любой машине сети
-
-
Настя
Пыталась выполнить на сервере (2003).выдало такую ошибку: netdom не является внутренней или внешней командой
-
admin Автор записи
Средства поддержки не устанавливаются автоматически в процессе установки пакета обновления 1 (SP1) для Windows Server 2003. Чтобы установить средства поддержки на компьютер с операционной системой Windows Server 2003, необходимо запустить установочную программу Suptools.msi, которая находится в папке Support\Tools на компакт-диске пакета обновления 1 (SP1) для Windows Server 2003.
-
Настя
Установила уже, но все равно не получается
netdom reset /d:Pss wks-pasport1.pss.local /server:pss-ad /uo:Stalovich_av /po:XXXX>>d:\List.Txt
И результат:
Не найден сетевой путь.
The command failed to complete successfully.
-
-
-
admin Автор записи
А контроллер домена и мпроблемная машина видят друг-друга?
если да то можно попробовать выполнить сброс с проблемной машины
Netdom Resetpwd /Server:pss-ad /UserD:Stalovich_av /PasswordD:*-
Настя
admin, «А контроллер домена и проблемная машина видят друг-друга?»
к сожалению не знаю. как это посмотреть 🙁
Компьютер- wks-pasport1 (стоит windows 7) на нем есть только локальный пользователь гость, а лок. админ не успела включить. Пробовала различными способами включить лок. администратора- результат- отказано в доступе
Уже посмотрю завтра, т.к. сотрудник уже ушел домой,
-
-
admin Автор записи
ping wks-pasport1
nslookup wks-pasport1-
Настя
admin,
команда ping wks-pasport1- выполнилась нормально,
а команда- nslookup wks-pasport1 выдает ошибку: Non-existent domain-
Настя
admin, у меня зона обратного просмотра вообще не настроена, сейчас читаю, как правильно ее настроить. Может быть в этом причина?
-
-
-
admin Автор записи
Хм. А эта машина вообще в домене была?
-
Настя
admin says:
Эта машина была в домене, затем переустановили windows7, я ее снова в домен ввела,всего несколько дней машина входила в домен, а потом просто вылетела… 🙁 -
Дмитрий
«имя_ПК_С_Ошибкой», я же болван, сижу намеренно делаю в имени ПК ошибку и думаю почему команда не выполняется. Потом дошло, имя ПК на котором выходит данная ошибка. 🙂
Maximalist 
admin 
Настя 
Дмитрий Добавить комментарий
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.