Вопросы Теги

Сценарий входа в систему Active Directory, не обновляющий

Два предложения:

(1) Тремя самыми важными сетевыми проблемами является DNS, DNS и DNS. Вы не упоминаете, выполняете ли Вы локальный сервер DNS, но мой опыт состоял в том, что 75% всех сетевых странностей и проблем могут быть непосредственно прослежены до проблем DNS. Удостоверьтесь, что Ваш DNS надежен перед движением дальше; звоните во внешние экспертные знания для взгляда при необходимости.

(2) Только с 40 пользователями в сети, почему бы не использовать статический IP? Это устранило бы DHCP полностью как источник горя, и Вы действительно не извлекаете много пользы из DHCP с небольшой LAN.

2
задан 10 November 2009 в 15:39
4 ответа

Это кажется, что Вы не знаете, выполняют ли пользователи новую версию сценария или старую версию. (Я предполагаю, что у Вас есть единственный контроллер домена и что это не проблема репликации файлов между DCS. Теоретически, это могло быть, но мы пойдем туда, только если Вы указываете на наблюдение проблем репликации с долей СЕТЕВОГО ВХОДА В СИСТЕМУ между DCS.)

Мой пищеварительный тракт говорит выполнение чего-то как "СЕТЕВОЕ ИСПОЛЬЗОВАНИЕ...", и у пользователей есть персистентные "отображения диска", включил. По сути, когда "СЕТЕВОЕ ИСПОЛЬЗОВАНИЕ..." пытается "отобразить" букву "диска", команда перестала работать, потому что "диск" уже "подключается".

Я добавил бы, что "СЕТЬ ИСПОЛЬЗУЕТ x:/D" на строке перед рассматриваемой буквой диска, как:

@echo off
NET USE Q: /D
NET USE Q: \\server\sharename

Это удаляет существующее "отображение" для "диска" Q: прежде, чем создать тот.

По умолчанию, эти "скрипты входа в систему прежней версии", запущенные видимый во время входа в систему. По сути, можно включить отладку строки "эхо" и/или "пауза" в конце сценария, затем войти в систему как пользователь и видеть то, что на самом деле выполняется. Это - Ваш лучший выбор, если Вы не можете добраться, он для работы - видит то, что на самом деле выполняется, и отладьте его.

2
ответ дан 3 December 2019 в 10:27

Походит на кэшируемую проблему профиля учетных данных/кэшировать. Попытайтесь выбрать одного пользователя (предпочтительно кто-то, кого это не повлияет на слишком много на), удаляя их локальный профиль на их ПК, и заставляя их войти в систему снова.

Если это работает затем, Вы, возможно, должны любому дать пользователям команду делать a gpupdate /force или выйти из системы и отступить максимум на 3 разах, прежде чем это умрет.

Если это не работает, у Вас может быть проблема, где пользователи аутентифицируются против другого DC в том, Вы внесли изменение на, и Ваша sysvol репликация повреждается. Давайте надеяться дело не в этом...

2
ответ дан 3 December 2019 в 10:27
  • 1
    Я соглашаюсь, кэшируемые учетные данные могут вызвать проблему, но никакую потребность удалить целый профиль, удалить только отображение под ключевым HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 –  alexm 10 November 2009 в 17:56
  • Вызовите обновление Групповых политик
  • Проверьте, что пользователи видят домен и могут синхронизироваться
  • Проверьте, что старые отображения были удалены, иногда они завинчены и могут быть удалены только вручную путем удаления записей MountPoints2 из реестра
0
ответ дан 3 December 2019 в 10:27

У нас была подобная проблема, где новые отображения диска не произошли, потому что старые отображения диска не были удалены.

Можно протестировать, если это - проблема

  1. отображение на новую (неиспользованную) букву диска - и если это работает
  2. задержите его к оригиналу, и затем вручную не отобразите диск до запущения скрипта.

Если это работает, то Ваш сценарий не не отображает диск правильно.

Надежда, которая помогает!

0
ответ дан 3 December 2019 в 10:27

Теги

Похожие вопросы