У меня есть сценарий миграции с файловой службой отказоустойчивого кластера, где я хотел бы добавить псевдоним для старого имени файлового сервера, указывающего на имя точки доступа клиента службы кластера.
Использование CNAME или A-RR с DNS и создание клиентских точек доступа для кластера достаточно просто, но моя проблема в том, что Cluster Manager разрешает только однокомпонентные имена CAP и, кажется, только добавляет к имени основной суффикс DNS. .
Итак, учитывая устаревшую файловую службу под названием \\oldserver.olddomain.example.com
и кластер CAP с именем oldserver
, имена, на которые будет отвечать кластерный CAP, будут \\oldserver.clusterdomain.example.com
и \\oldserver
. Кажется, я не могу получить ответ на \\oldserver.olddomain.example.com
при моих попытках доступа он выдает 0x80004005 (неопределенная ошибка).
Трассировка пакета показывает ответ SMB2 IoCtl, упакованный с STATUS_ACCESS_DENIED с IP-адреса CAP после того, как мой клиент установил Tree Connect и отправил FSCTL_VALIDATE_NEGOTIATE_INFO запрос.
В «Как настроить псевдоним для кластерного общего ресурса SMB» сообщение в блоге предлагает установить псевдоним с помощью Set-ClusterParameter. К сожалению, он не принимает полные доменные имена либо из-за ошибки «Формат указанного сетевого имени недействителен»
Я также уже зарегистрировал SPN для oldserver.olddomain.example.com
и oldserver
к учетной записи компьютера домена CAP, поэтому Kerberos не должен быть проблемой.
Редактировать: добавление DisableStrictNameChecking
в реестр узлов кластера, к сожалению, тоже не помогает.
Я должен был перезагрузить своего клиента (ов) перед тестированием - это помогло бы. Оказывается, речь идет вовсе не об иностранных доменах, а просто о временной проблеме проверки подписи SMB.
- Клиент Windows 8 сопоставляет общий ресурс на сервере с диалектом SMB 2.1, высшим диалектом сервера.
Пример использования команды Powershell: New-SmbMapping -LocalPath Y: -RemotePath \ FileServer \ Share
Сервер отключает TCP, и его программное обеспечение обновляется до версии, поддерживающей SMB 3.0.
Клиент согласовывает диалект SMB 3.0, самый высокий диалект новейшего сервера, и пытается повторно подключиться к тому же общему ресурсу.
Серверу не удается проверить подпись, отправленную клиентом в IOCTL FSCTL_VALIDATE_NEGOTIATE_INFO. Сервер возвращает клиенту ошибку ACCESS_DENIED.
[...]
Возможный обходной путь - отключить клиент Windows 8 и удалить это соединение / сеанс, прежде чем он сможет повторно установить новое соединение. Для этого требуется отменить сопоставление диска (и подождать около 20 секунд, пока клиент очистит данные, связанные с этой записью подключения), а затем повторно сопоставить его.
Перезагрузка клиента также приведет к тому же результату, но это не обязательно.
1: У меня есть это
2: Я сделал это