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

Это не подставной клиент, это proxy заглушка доступ осуществляется через нее и здесь же осуществляется контроль доступа. Смысл изначально остался и был перенесен в COM+ И заключается он в следующем:

Для COM-компонента создается прокси сервер, который содержит информацию местоположении компонента и информацию для маршалинга (сигнатуры интерфейса) в общем все что необходимо для локального вызова (а в COM+ еще и сигнатуры доступа по моему) эта прокси переноситься на хост-клиент компонента и далее вызов осуществляется обычным путем. Заглушка на хосте компонента зарегистрирована и содержится в депозитарии DCOM компонентов. Когда на хост приходит RPC вызов, служба депозитария осуществляет поиск компонента и доступ к нему через его заглушку. По какой то причине этот механизм показался OPC foundation не привлекательным. В связи с чем они разработали свой интерфейс без инсталляции на клиенте прокси. Интерфейс OPC стандартизирован и информация о маршалинге содержится в библиотеках самого клиента, для перечисления  OPC серверов используется либо удаленный реестр (устарело) либо OPCenum энумератор OPC серверов хоста. Поэтому достаточно только указать хост и имя OPC сервера что бы к нему обратиться, но DCOM должен быть запущен.

По настройке сетевого клиента NT пожалуй ничего не смогу посоветовать, дело в том, что клиент был переделан и нормально работать с предыдущими версиями работает если то криво в режиме совместимости. Думаю, что если вы хорошенько поковыряете MSDN то наверняка найдете какой нить материал по теме.

Это так было не всегда у Вас видимо WinXP ИМХО они уже слишком заморочились с безопасностью. Мне суть даже их текущей концепции не ясна, смысл в том что видимо они при любой неоднозначности стремятся разделить клиентов по сессиям, весьма спорно и для нашего случая неприемлемо за частую, но это так. Если требуется рулить пользователями на локальных клиентах рекомендую использовать ярлык для запуска клиента и его функцию запуск от имени. Благо что почти во всех OPC’вых СКАДА’х система безопасности не завязана на виндовую, да и вообще зачастую имеет достаточно примитивный характер. Скоро если только OPC не переедет на COM+ где все достаточно прозрачно настраивается будет все сложнее поддерживать эту структуру если конечно не пренебрегать безопасностью (мануалы по настройки OPC извините меня за скудность речи но это полная лажа блин “ВСЕ” в админы, руби Баха даешь металл).

Еще найдите Ваш OPC сервер в списке DCOM компонентов и убедитесь, что он использует умолчальные настройки запуск под текущим пользователем вполне возможно, что он имеет индивидуальные настройки. Так же настоятельно рекомендую посетить сайт покинувшего наши нестройные ряды непоклонников Билла, господина Русиновича http://www.microsoft.com/technet/sysinternals/default.mspx и дернуть там Process Explorer

который лучше чем стандартный диспетчер задач и позволит отслеживать все сессии по именам. На многие вопросы позволит ответить самостоятельно.

;-) Так же бывают глюки, если иметься запущенный компонент и права на запуск клиент не имеет, он как то уж видимо от безысходности находит уже запущенную копию, попробуйте еще и так…

К вопросу о поведении OPC сервера при изменении настроек в dcomcnfg могу еще добавить следующее. В принципе приложение может не реагировать на изменение настроек, так как возможны варианты реализации:

1. Игнорирующие систему безопасности, тесть реализующие анонимный доступ к компоненту так работают все компоненты под DCOM на Win98 и ниже, ибо для этого DCOM безопасность не реализована в принципе. Например компания GigaByte для своих системных драйверов (chipset) реализовала по DCOM для анонимного доступа систему сбора информации об установленном оборудовании, ИМХО это уже Троян. Естественно если OPC реализовать таким образом он будет работать всегда если запущен DCOM. В этом случае можно пойти еще дальше и построить свой механизм минующий службу вызова удаленных процедур (не механизм, а именно службу) за руки GigaByte никто не держал и они и это сделали.

2. Зашить параметры доступа в компонент и игнорировать настройки реестра, тогда хоть заменяйся параметры доступа будут не выше чем зашиты

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

Так что вопрос о кривости серверов вполне правомерен.

Особых каких то камней тут нет на мой взгляд, есть даже одно неоспоримое преимущество. Дело в том что зачастую при подключении к OPC его еще нужно запустить и вот тут и начинаются основные проблемы. Если OPC выполнен как сервис то при режиме запуска “авто” он при первом обращении уже тепленький и готов к работе. Хотя если намудрить с настройками DCOM можно и в этом случае увидеть вторую копию ;-). Кстати есть простая достаточно возможность запустить любую программу как сервис, фреварного барахла делающего это более чем предостаточно. Сервис от программы отличается только дополнительным интерфейсом для управления собственно и все.

Кстати сервис может быть запущен под любым пользователем, не только SYSTEM