Почему Server 2016 и server 2003 не понимают друг друга?

Question

[ADarkin]

Есть домен, DC - Server 2016. Среди всего прочего в сети есть старенький сервер 2003 R2 - просто файловая свалка для юзеров. Недавно 2016 накатил массу обновлений, и началась проблема: на сервер 2003 невозможно зайти проводником в шары по имени сервера (а у юзеров ярлыки на раб. столах \\servername\share), но по ip - \\192.168.x.x\share прекрасно заходят. При этом из cmd он по имени с юзерских компов пингуется, в DNS записи есть. Всякие ipconfig /flushdns, перезагрузки всего и т.п. не помогают...

Comments

[Drno]

включить SMB1 если он выключен
но вообще начиная с вин10 МС сломали же шары.. при том конкретно так

[Ziptar]

Если servername это не fqdn, то может накрылся wins сервер, если он был, или разрешение имен netbios отвалилось

[ADarkin]

Drno, на DC1 smb1.1 включен, ему это не помогло. на старый комп с ХР заходит без проблем. Но большинство юзеров сидит на Win7, те которые на Win10 - smb1.1 тоже везде включен.

[ADarkin]

Ziptar, fqdn не помогает.
DC (2016) и есть WINS сервер.. посмотрел - WINS работает, и этот старый 2003 у него в записях фигурирует.

[aleks-th]

Я бы собственно задался вопросом так ли нужно поддерживать такое старье как 2003 - 22 годика системе столько не живут.
Хотя и 2016 уже достаточно древненькая..

Мы помню у себя в 2010-2012 годах искореняли все 2003... как морально устаревшие...

[aleks-th]

Вот рецепт от чатгопоты.:

Проблема, которую вы описали, связана с разрешением имен в сети. Если компьютеры не могут найти сервер по имени, но могут подключиться по IP-адресу, это указывает на проблемы с DNS или NetBIOS. Вот несколько шагов для устранения проблемы:

1. Проверка DNS

Убедитесь, что на сервере Windows 2003 настроен правильный DNS-сервер (например, ваш роутер или внешний DNS-сервер).

Проверьте, есть ли запись для сервера в DNS. Для этого:

Откройте консоль DNS (dnsmgmt.msc).

Проверьте, есть ли запись A (адресная запись) для имени servername в зоне, соответствующей вашему домену или рабочей группе.

Если записи нет, создайте ее вручную.

2. Проверка NetBIOS

Убедитесь, что служба NetBIOS включена на сервере и клиентах.

Проверьте настройки NetBIOS в свойствах сетевого адаптера:

• Перейдите в Сетевые подключения.
  
• Откройте свойства сетевого адаптера.
  
• Выберите Протокол Интернета (TCP/IP) и нажмите Свойства.
  
• Нажмите Дополнительно, перейдите на вкладку WINS.
  
• Убедитесь, что выбрана опция Включить NetBIOS через TCP/IP.
  
  

Если NetBIOS отключен, включите его.

3. Проверка файла hosts

На клиентских компьютерах проверьте файл hosts (расположен в C:\Windows\System32\drivers\etc\).

Убедитесь, что там нет неправильных записей для servername.

Если запись отсутствует, добавьте строку:
Copy

192.168.x.x servername

4. Проверка рабочей группы/домена

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

Если сервер и клиенты находятся в домене, проверьте, что клиенты корректно аутентифицируются в домене.

5. Проверка брандмауэра

Убедитесь, что на сервере Windows 2003 брандмауэр или сторонний фаервол не блокируют NetBIOS или DNS-запросы.

Откройте необходимые порты:

NetBIOS: порты 137, 138, 139.

SMB: порт 445.

DNS: порт 53.

6. Проверка служб

Убедитесь, что на сервере запущены следующие службы:

DNS-клиент (если используется DNS).

Служба NetBIOS.

Служба браузера компьютеров.

Перезапустите эти службы, если они работают некорректно.

7. Обновление системы

Убедитесь, что на сервере и клиентах установлены последние обновления Windows. Некоторые проблемы могут быть связаны с устаревшими версиями ОС.

8. Использование WINS (опционально)

Если в сети используется WINS-сервер, убедитесь, что на сервере и клиентах настроен правильный адрес WINS-сервера.

Добавьте WINS-сервер в настройках TCP/IP (как описано в шаге 2).

9. Перезагрузка

После внесения изменений перезагрузите сервер и клиентские компьютеры.

Если после выполнения этих шагов проблема не решена, возможно, стоит рассмотреть возможность обновления сервера, так как Windows Server 2003 является устаревшей и не поддерживается Microsoft.

[aleks-th]

Собственно я когда с таким сталкивался, прописывал Wins и все начинало работать.

[ADarkin]

aleks-th, ну, это как раз бесполезные советы из учебника, потому что ответ на все вопросы: да, всё проверено. все компы и сервера вдомене,и DNS в полном порядке, и WINS тоже.. и все сетевые настройки в полном порядке. и hosts ни при чём - я вообще стараюсь его не использовать без крайней необходимости, это ж надо бегать по всем компам, его переписывать, а если что-то изменится, то заново..

[ADarkin]

aleks-th, WINS прописан и никуда не делся. фокус в том, что всё это началось именно после накатки множества обновлений на контроллер домена, сервер 2016, который заодно и WINS сервер..

[ADarkin]

aleks-th, да были уже мысли, но там старенький сервер, единственная ценность которого на данный момент - неплохой аппаратный RAID :-)
там просто больше десятка расшаренных папок с 300+ Гб документов, с подробно расписанными правами по юзерам/отделам- как представлю что всё это после переустановки расписывать заново... %-)
это из серии "работает - не трогай!", и вот...

[Ziptar]

ADarkin, не очень понимаю что требуется расписывать после переустановки. Сервер в домене же? Права ntfs никуда не денутся.

[ADarkin]

Ziptar, не столько ntfs, сколько сетевые права на шары подробно расписаны. ntfs-ными я особо не заморачивался, незачем.

[Ziptar]

ADarkin, ну, собсно, зря; это как smb-шными правами заморачиваться незачем в общем случае

[MaxKozlov]

Если что, subinacl умеет сохранять и восстанавливать выданные права

https://ss64.com/nt/subinacl.html

[MaxKozlov]

ну и это "невозможно зайти" обычно какой-нибудь номер ошибки даёт получить или из net use или из event log
а уж по нему надо смотреть

[Роман Безруков]

ADarkin, не надо ничего расписывать...
раньше был File Server Migration Toolkit, сейчас - Storage Migration Service. И тот, и другой умеют переносить данные с сохранением прав доступа - причем практически без прерывания сервиса или с минимальным простоем.
да и robocopy с ключом /copyall умеет сохранять права

Answer 1

[MVV]

Копать тут - в поддерживаемые протоколы шифрования для Kerberos: недоступность по имени при доступности по IP - вообще типичный признак проблем с Kerberos, а тут ещё в наше время MS повадилась отключать старые протоколы как "небезопасные" - потому что безопасность (показная) стала продаваемой, ее якобы наличие увеличивает ценность продукта в глазах клиентов.

Comments

[ADarkin]

попробовал:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Network security: Configure encryption types allowed for Kerberos security policy setting.

в политиках и домена, и доменконтроллера, повключал на всяк случай всё, что есть.
после gpupdate /force некоторых стало пускать, но не всех.. как-то избирательно. с самого DС - так и не пускает.. с компа с win11 - без проблем...

Answer 2

[Алиса]

Попробуйте включить поддержку SMB 1.0 на Server 2016

Comments

[ADarkin]

если бы он был выключен, то не смогло бы зайти ни по имени, ни по ip

[Алиса]

ADarkin, не факт, возможно при обращении по ip используются другие методы аутентификации, w2k3 под руками нет. так что явно проверить не смогу. Попробуйте включить smb1 на какой нибудь пользовательской машинке и проверить обращение по dns

но блин, 2003... что для файловой помойки. можно же какой-нибудь никсовый сервак поднять из г:?* и палок.

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

[ADarkin]

Алиса, smb 1.0 включен везде, изначально, именно для этих случаев. *никсовый сервер не хочу, т.к. совместимость самбы с виндовской моделью прав "оставляет желать лучшего", я на эти грабли уже наступал.

[Алиса]

Убедитесь, что на Server 2003: Включена опция Register this connection's addresses in DNS (в свойствах TCP/IP).
Убедитесь, что NetBIOS over TCP/IP включен в настройках сети Server 2003 и клиентов.
На DC (Server 2016) через Group Policy (gpedit.msc или доменные политики): Отключите Microsoft network client: Digitally sign communications (always) и Microsoft network server: Digitally sign communications (always)
На Server 2003 разрешите входящие подключения для File and Printer Sharing (порты 139, 445, UDP 137-138).
На клиентах разрешите исходящие подключения по SMB.
На DC временно разрешите NTLM

хм.. что еще упустила..
если еще мысли будут напишу