[gl00mie]

Цитата:

Сообщение от otkudao

- виртуалка подключена под bridge; Ip хоста 10.ХХХ.75.17, ip VmWare - 10.ХХХ.75.15, то есть они в одной подсети

Замечательно, значит, проблем с NAT и тому подобным быть не должно. Скажу наперед, что скорее всего понадобится-таки включить виртуальную машину в домен...

Цитата:

Сообщение от otkudao

- MDAC версии - ЭТО в Драйверах "SQL native Client" и "SQL Server"?

Да, только для использования SQL Native Client нужна отдельная настройка в конфиге, иначе будет использоваться драйвер SQL Server 2000. Для 3-ки в конфиге должно быть прописано: sqlparm,Text,DRIVER={SQL Native Client}

Цитата:

Сообщение от otkudao

Но после успешного наката новой инсталляции MDAC ДАТА в этой таблице не поменялась... Я так понимаю, что это дата инсталляции. Я правильно смотрю?

Отображаемая там дата - это дата последней модификации файла.

Цитата:

Сообщение от otkudao

- "отфильтровав трафик по порту, на котором он висит, посмотреть, смог ли клиент достучаться до AOS'а или нет."
я без утилит вижу, что клиент до AOS не достучался.

Не... без утилит видно, что клиент не подключился, а вот по какой причине не подключился - это надо выяснить: не нашел сервер по доменному имени, или нашел, но не смог достучаться по TCP, или смог, но не смог подключиться по RPC, или смог подключиться, но был послан AOS'ом... Под "достучать" я понимаю наличие соединения по TCP.

Цитата:

Сообщение от otkudao

Мне бы диагноз поставить, почему. А утилиты этого не показывают (или я не знаю, куда смотреть Использую Network Monitor

Во-первых, при захвате трафика либо при его последующем просмотре надо поставить фильтр, чтоб не видеть не относящейся к делу ерунды. Фильтр ставится по порту TCP, чтобы видеть только трафик между клиентом и AOS'ом, и по наличию данных в TCP-пакете, чтоб не видеть всякие служебные TCP-пакеты. Фильтр должен выглядеть примерно так: TCP.Port==2712 && TCP.TCPPayload. посмотрим, как примерно выглядит результат успешного (на первый взгляд ) и неуспешного подключения к AOS'у после применения фильтра.
При подключении по RPC с NTLM-авторизацией сначала идут три пакета: Bind (от клиента к серверу), Bind Ack (от сервера к клиенту) и Bind Resp (от клиента серверу; в последних версиях NetMon его обозвали Auth3). На этом этапе собственно происходит challenge-response авторизация клиента на хосте AOS'а с использованием NTLM. Затем клиент посылает запрос (RPC-пакет типа Request) той службе, к которой он по RPC попытался подключиться. При неуспешном подключении по причине невозможности авторизоваться по RPC (скорее всего, у вас картина будет именно такая, если клиенты могут достучаться до AOS'а) вместо RPC-пакета с ответом (Response) он получает RPC-пакет с типом "ошибка" (Fault), в статусе которого может быть указано, по какой причине произошла ошибка. В приведенном примере статус 0x00000005 по всей видимости означает "отказано в доступе".


В случае успешной авотризации при установлении RPC-соединения клиент получит в аналогичной ситуации ответ от службы, к которой он подключился, в виде RPC-пакета типа Response.

Здесь уже в дело вступает непосредственно RPC-интерфейс, используемый клиентом и сервером, без знания конкретики которого с помощью NetMon'а разобраться будет сложно. Но применительно к Аксапте мы, по крайней мере, получим «внятное» сообщение об ошибке, типа "unable to logon" или что-то в этом духе.