WTware клиент RDP

По поводу номеров портов ... как это будет объяснять по русски?

Ну, примерно так:

Программы нижнего уровня (на уровне BIOS) работают не с именами последовательных портов, а с их номерами, привязанными к "железным" разъемам.
По умолчанию:
0000h-COM1, 0001h-COM2, 0002h-COM3, 0003h-COM4

Но та же самая Винда может переименовать порты или добавить устройства (аппаратные или виртуальные) с дополнительными портами.
Т.е. имена COMnn могут быть разными. Так что логическая связь имени COMnn с разъемом теряется.
А физические номера этих "железных разъемов" остаются прежними.

Т.е., мне кажется, логичнее было бы не serial=com2(com1), а serial=com2(0), назначая виртуальному порту com2 на сервере железный порт с номером 0 на терминале.

Как-то так. Мне это кажется понятнее. Хотя, может я и не прав. В том смысле, что проброс портов с этими номерами не знаком. а оперирует как раз их именами.

Дал виртуальному порту сервера имя SCAN (недостаточно экзотическое, зато короткое). Результат отрицательный - тоже ошибка получения монопольного доступа.

Pochemuk писал(а):Только почему имена необычные? scaner=com2(com1) как раз самые обычные имена использует - соотносит виртуальный com2 сервера с реальным com1 терминала. Но могу и попробовать serial=scanner(com1).

С обычными понятно, работать будет. Если scanner недостаточно необычное имя для ком-порта, попробуй так:

serial=medved(com1)

Pochemuk писал(а):Почему эта команда оперирует с логическими именами портов терминала, а не с их физическими номерами? Может это и удобнее, но как-то не строго получается.

Что такое "физический номер порта"? С нашей линуксовой стороны эта команда обращается к /dev/ttyS0, или там к /dev/ttyACM0. Предлагаешь пугать администратора виндовсов этими линуксовыми ругательствами?

Попробую чуть погодя, когда запарка пройдет. А то из-за этих сканеров перенос затянулся почти на 3 дня. А текучку никто не отменял

Только почему имена необычные? scaner=com2(com1) как раз самые обычные имена использует - соотносит виртуальный com2 сервера с реальным com1 терминала. Но могу и попробовать serial=scanner(com1).

Заодно вот какой вопросец:

Почему эта команда оперирует с логическими именами портов терминала, а не с их физическими номерами? Может это и удобнее, но как-то не строго получается.

Чудеса, да.

А если писать что-нибудь вроде serial=scanner(com1), будет работать? Видит оно порты с необычными именами?

aka писал(а):Я при непонятных проблемах переставляю сервер

Другой какой-нибудь программой (любым терминалом, например putty/kitty, или чем-нибудь специально под com-порты обученным) получается открыть порт и принимать коды со сканера? Никакого протокола при общении со сканером нет, надо только открыть порт с правильной скоростью - и в него должны посыпаться сканируемые цифры.

Через mstsc.exe на тот же сервер с виндовс-машины сканер перенаправляется и работает?

В общем, проблема решилась просто и неожиданно. В конфигурациях терминалов вместо serial=com1 прописали serial=com2(com1). Или просто serial=com2, где сканер был ко второму порту терминала подключен.

И, чудо, все заработало!

Похоже, что-то в самом Win2K12 R2 не давало подключаться к COM1, даже если в системе его нет (физический serial0 переименован в логический COM11).

Я при непонятных проблемах переставляю сервер

Другой какой-нибудь программой (любым терминалом, например putty/kitty, или чем-нибудь специально под com-порты обученным) получается открыть порт и принимать коды со сканера? Никакого протокола при общении со сканером нет, надо только открыть порт с правильной скоростью - и в него должны посыпаться сканируемые цифры.

Через mstsc.exe на тот же сервер с виндовс-машины сканер перенаправляется и работает?

Нет, там все работали очень зажатыми групповыми политиками терминальными пользователями

Администратором, кстати, тоже не получается ...

Может быть scanOPOS и древняя, но работала стабильно и на терминальном сервере под Win2K3 R2 и под Win2K12. На новом серваке используется та же самая библиотека. В чем причина - уже всю голову за 2 дня сломали. В Инете встречаются похожие ситуации связанные как раз с DLL. Но она же у нас рабочая!!!

Может, на старом все работали Администраторами, а scanopos.dll древняя и негодная для нормальных терминалов?

Не видел такую ошибку. Никаких особых танцев для доступа к портам делать не надо. Оно из коробки должно работать.

День добрый!

Суть проблемы в следующем:

Был сервер терминалов под управлением Win2K12. Но это последнее время. А до этого он еще долго работал под Win2K3 R2. Отработав благополучно около 10 лет он выпучил конденсаторы, нагрел оперативную память и радиаторы чипсетов до 100°C и стал зависать по несколько раз на дню.

Было решено его поремонтировать, а пока что перевести всех его пользователей на другой сервер поновее под управлением Win2K12 R2.

Проблема обнаружилась при настройке сканеров штрих кодов, подключенных для снятия информации в 1С-предприятие.

Сканеры были достаточно старые и подключались к последовательным портам. И на новом севере они работать отказывались. в 1С при попытке подключения оборудования к последовательному порту выдавалось сообщение, что невозможно получить монопольный доступ к порту.

Драйверы сканера использовались аналогичные - стандартный ScanOPOS из 1С.

Настройки терминала аналогичные (только изменен IP сервера). На новом сервере заменили номера портов COM1 и COM2 на COM11 и COM12. Команда change port выдает следующее:

AUX = \DosDevices\COM1
COM1 = \Device\RdpDrPort\;COM1:NN\\tsclient\COM1
COM11 = \Device\Serial0
COM12 = \Device\Serial1

где NN может быть различно.

Что заметили: На старом сервере NN меняется крайне редко. Обычно принимает значения 1 или 2. На новом сервере оно меняется постоянно при каждом включении терминала и может принимать как однозначные, так и двузначные. Может ли это как-то быть связано?

Как еще понять, что мешает драйверу получить монопольный доступ?