Групповые политики, не относящиеся к определенному серверу
Вы получили доступ к Базе знаний для Office IP? В противном случае я запустил бы там и выбрал бы руководство, которое лучше всего соответствует. http://marketingtools.avaya.com/knowledgebase/ Нажимает на "IP Office Technical Manuals", затем Вы будете видеть ряд выпадающих меню в верхней части страницы. В последнем поле выберите "Manuals" из списка выбора. Список руководств появится, которые предоставляют инструкции от различных установок
Мы реализовали это в нашей школе, потому что у нас заканчивались IP-адреса и мы предоставили новую подсеть для беспроводной секции, отлично работает в сети с 3000 пользователей, быстрое решение является плюсом, Я согласен, что мы должны создать виртуальные локальные сети для обеспечения безопасности.
DHCP-сервер (Windows) должен иметь две карты nic, подключенные к одному и тому же коммутатору (наша виртуальная, поэтому это не имеет значения), чтобы выдавать IP-адреса на беспроводной сети, вам придется использовать статические IP-адреса в «старой сети», она не будет работать с двумя областями DHCP через один и тот же коммутатор.
В конце концов, выделенное серым цветом поле присоединения к домену было той подсказкой, в которой я нуждался, указывая на проблему с лицензией Windows. Когда я набрал ключ MAK и ввел информацию о KMS через cscript
cscript slmgr.vbs / ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx как и должно быть, все начало работать именно так, как вы ожидаете.
Надеюсь, это поможет другой бедной душе выбраться из беды. месяц дополнительной работы.
Вы не упоминаете, выполняли ли вы RSoP, но это будет моим первым шагом. Кроме того, показывает ли сервер какие-либо признаки «применения компьютерной политики» во время запуска?
Получив результаты RSoP, вы можете по крайней мере увидеть, считает ли сервер, что это следует применять политики (если ничего другого, политики домена / пользователя по умолчанию).
- Начать редактирование - Просто перечитайте и заметьте, что вы запустили GPRESULT. Поэтому я бы продолжил мониторинг процесса (см. Ниже). --End Edit--
My next step would be to use Microsoft SysInternals Process Monitor in boot logging mode to see what's happening.
Also, another thing I've tried in the past is to use PsExec to launch a command prompt, running as the local SYSTEM account. You can then perform a simple directory listing of the policies area in SYSVOL. Bearing in mind that policy application/filtering is controlled by good-old NTFS ACLs. If you're able to see the policies* (and these will be the computer policies), you have another issue.
*Policies are listed in SYSVOL using their GUIDs, but these can be resolved by querying AD (or browsing around using ADSIEDIT, or similar). If you need the LDAP path, shout.