Windows server отключается сеть

Обновлено: 07.07.2024

С этим сервером у меня есть 2 проблемы, обсуждение этих проблем в русскоязычном сегменте я не нашел:

1. Hyper-v, поднятый на 2019 сервере не завершает корректно работу виртуальных машин при своем выключении.

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

2.Eсть ноутбук Dell 5468, под управлением windows server 2019 Datacenter, не подключается к телевизору по miracast (widi).

Для справки: Все это работало в этом же аппаратном наборе, но ноутбуке стоял Server 2016, перестало работать после апгрейда на 2019. Если поставить начисто 2019 тоже не работает, проблема явно в Server 2019. С других двух компьютеров, где Win 10 с этим телевизором все работает, значит он в порядке, если на ноутбук снова поставить начисто server 2016, то тоже работает, значит ноутбук впорядке.

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

В логах есть такая ошибка:

Имя сбойного приложения: ShellExperienceHost.exe, версия: 10.0.17763.1, метка времени: 0x5b9c8bd8

Имя сбойного модуля: ntdll.dll, версия: 10.0.17763.348, метка времени: 0xca65c822

Код исключения: 0xc0000005

Смещение ошибки: 0x0000000000033fc8

Идентификатор сбойного процесса: 0xcc4

Время запуска сбойного приложения: 0x01d4d59d7b0e2b2c

Путь сбойного приложения: C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe

Путь сбойного модуля: C:\WINDOWS\SYSTEM32\ntdll.dll

Идентификатор отчета: 9dc3dd63-7d96-4ebb-9052-433a5b6cc03c

Полное имя сбойного пакета: Microsoft.Windows.ShellExperienceHost_10.0.17763.1_neutral_neutral_cw5n1h2txyewy

Код приложения, связанного со сбойным пакетом: App

Ну вот собственно все, возможно найдутся люди у которых те же проблемы, ну и может кто-то из Майков обратит внимание на это.

Как в Windows Server 2019 включить сетевое обнаружение

На компьютерах, которые должны подключаться к общей сетевой папке, перейдите в «Изменение расширенных параметров общего доступа» и выберите опцию «Включить сетевое обнаружение»:


Затем нажмите кнопку «Сохранить изменения».

Вновь откройте «Изменение расширенных параметров общего доступа» и проверьте сделанные настройки.

В настоящее время Windows Server 2019 не сохраняется «Включить сетевое обнаружение».

Для включения сетевого обнаружения (network discovery) необходимо, чтобы были запущены определённую службы.

Откройте services.msc и убедитесь, что запущены следующие службы:

  • DNS Client
  • Function Discovery Resource Publication
  • SSDP Discovery
  • UPnP Device Host

Если у вас русскоязычная версия, то службы называются так:

  • DNS-клиент
  • Публикация ресурсов обнаружения функций
  • Обнаружение SSDP
  • Узел универсальных PnP


Затем снова включите сетевое обнаружение — теперь настройка должна сохраняться и SMB и другие связанные функции должны работать.

Связанные статьи:

Рекомендуется Вам:

Comments

Дякую! Допомогли вирішити дану проблему )

Не помогло. Брэндмауэр отключил даже. И все равно сервер никто не может дажи пинговать. Хотя сервак пингует ПК

Если у вас другие проблемы с доступом к сетевой папке, то посмотрите, например, разделы, посвящённые созданию сетевых папок с паролем и без пароля. Там же написано, как подключаться к сетевой папке — нюансов много.

Что касается пинга Windows хостов, то особо на это не стоит обращать внимания, так как по умолчанию все Windows машины настроены не отвечать на пинги. То есть если машина не отвечает на пинг, то это не означает, например, что не будет доступа к сетевой папке, которая размещена на ней.

Привет. Недавно столкнулся с очень неприятной ситуацией — часть серверов начала самопроизвольно выключаться. Какой — либо закономерности в выключениях проследить не удавалось. Единственное что объединяло серверы — это то что на них была установлена ОС Windows Server 2012 или выше, и большая их часть имеет роль терминальных. Ах да, еще все эти серверы — виртуальные и работают под управлением Hyper V. Хочу сегодня рассказать, в чем была проблема.

Конечно, любая диагностика должна начинаться с анализа логов. И вот какое событие удалось обнаружить непосредственно перед выключениями серверов – событие 1074, user32:

The process C:\Windows\system32\winlogon.exe (DC) has initiated the power off of computer DC on behalf of user NT AUTHORITY\SYSTEM for the following reason: No title for this reason could be found

Reason Code: 0x500ff

Shutdown Type: power off

Comment:

Событие о выключении сервера

По ним становится понятно, что работа завершается штатно. Что в общем то позволяет исключить влияние железа, хотя оно и так было исключено, т. к. все серверы виртуальные. Под подозрение попал гипервизор, но рысканье вдоль и поперек по логам ни какого результата не дало. События относящиеся к завершениям работы не имели отношения к инициализации завершения работы. Говорят, что виртуальные машины могут в редких случаях произвольно выключаться, если есть проблемы со свободной памятью, но в моем случае памяти было более чем достаточно.

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

Обратите внимание на нижний угол:

Завершение работы

Да, это мать его, завершение работы системы. Оказывается с 2012 винды MS сделали эту кнопку доступной при подключении по RDP.

Отвечает за эту кнопку параметр в групповой политике -

Computer Configuration – Policies – Windows Settings – Local Policies – Security Options – Shutdown: Allow system to be shut down without having to log on.

Групповая политика

Отключаем его и всё, возможности выключить сервер у пользователей не будет.

Почему в моем случае этот параметр оказался включенным - остается загадкой. Скорее всего кто-то когда-то давным-давно его включил. Хотя, не исключаю, что он оказывается включенным при переходе с 2008 домена, проверять, честно говоря, лень. Кто в курсе, напишите в комментариях, в каком состоянии находится этот параметр при добавлении контроллера домена Windows 2012 в домен с уровнем 2008r2 или ниже.

В общем и целом, после изменения этого параметра мистические выключения прекратились.

Полезная информация об администрировании пользовательских и серверных ОС Windows.


В свойствах виртуального сетевого адаптера нужно установить ip-адрес 192.168.137.1 (если он автоматически не установится при открытии общего доступа).


telnet 192.168.215.158 7778

Вот текст скрипта:

В последних строчках скрипта запрещается и снова разрешается общий доступ для обоих адаптеров. Если это сделать только для одного (основного), то у меня возникала ошибка 0x80040201. А в этом случае ошибки нет.

А тут я описал как этот скрипт можно запускать при включении компьютера.

Это костыль, однако вариантов решения проблем с созданием бриджа и пропаданием интернета я пока не нашёл.

(РЕШЕНО) Общий доступ к подключению к Интернету пропадает при перезагрузке (Windows 10) : 10 комментариев

неужели нету более нормального варианта ?

перед этим еще дополнительно проверил что не только перезагрузка компьютера но и перезагрузка службы ICS тоже влияет на общий доступ к кассе.

создать параметр DWORD32 в реестре по пути:
Компьютер\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedAccess

Всем привет! Спасибо за подсказочку!
Снимать вручную и ставить галочку раз месяц тоже решение проблемы:)
Но так гораздо лучше!

Хороший скрипт, спасибо помог. Но как убрать окошко об успешном выполнении скрипта. с кнопкой ок.

1. Создать параметр DWORD32 (и для 64 bit) в реестре по пути:
Компьютер\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\SharedAccess
EnableRebootPersistConnection = 1

2.Службы
Общий доступ к подключению к Интернету (ICS)
Обязательно поставить (если не стоит) Тип запуска: АВТОМАТИЧЕСКИ
3. Перезагрузиться

не работает на свежей десятке

Читайте также: