удаленное подключение к OPC серверу

fakel15
Расписывать все возможные варианты настроек долго, вы так и не ответили

По поводу разницы сетевой архитектуры:

Когда мы создаем пользователя, то для системы большого значения его имя не имеет, самое главное это SID (Security Identifier) который частично состоит из Сида машины частично генерируется случайным образом. Если машины находятся в рабочей группе, то каждый хост имеет свою локальную, соответственно изолированную от других базу безопасности. В таких условия удаленная авторизация была бы невозможна в принципе, если не принять некоторые допущения, которые тем не менее считаются угрозой безопасности. Допущение состоит в том, что два одноименных пользователя, созданные каждый на своем хосте,  считаются равными, несмотря на то, что имеют разные идентификаторы (SID). Как только мы входим в домен, то это допущение перестает работать, и при доступе к хосту требуется явное указание базы безопасности (имя домена имя хоста). Более того, по умолчанию первичная проверка осуществляется в базе безопасности домена (не в локальной базе).

Так что можно прийти к следующему выводу:

При работе в рабочей группе достаточно иметь одноименного пользователя с необходимыми правами на обоих хостах

При работе в домене проще воспользоваться проадминистрированным доменным пользователем.

По поводу режима запуска. Самая жестокая ошибка по мнению спецов по DCOM это определенный по умолчанию режим запуска взаимодействующий пользователь. То есть грубо говоря (WinXP) для взаимодействующего пользователя открывается новая сессия, в которой осуществляется запуск OPC сервера, при этом если самому об этом не позаботиться то с очень высокой вероятностью OPC в этой сессии не увидит своего конфигурационного файла и стартует без тэгов. Часто бывает, что это будет вторая копия сервера, одна для консольной сессии (которая нормально работает) одна для “взаимодействующего пользователя”.

Самый простой вариант запуска это текущий пользователь, это гарантирует что сервер стартует в сессии текущего (залогиненного локально пользователя). Но для этого нужно обеспечить эту сессию как минимум (то есть использовать автологон) В общем как говориться выбирай но осторожно. Третий режим “указанный пользователь” мне изначально показался панацеей, пока я вдруг с удивлением не заметил, что (WinXP) предоставляет серверу отдельную сессию даже если локальная сессия совпадает с указанным пользователем мы имеем два экземпляра сервера.

Дико извиняюсь, за скудность речи, но не стоит путать теплое с мягким.

DCOM (Distributed Component Object Model) Это технология предоставляющая приложениям win32 прозрачно взаимодействовать между собой напрямую через сеть. Единственная ее задача это трансляция RPC вызовов по любому установленному в системе сетевому протоколу, то есть DCOM использует сеть и в модели OSI стоит на самом верхнем уровне. А в Вашем случае я бы начал брандмауэра который собственно и блокирует нормальную работу сетевого клиента WinNT . Для начала остановите его может этого будет достаточно.