Я распространяю утилиту для разработчиков, которая предназначена для размещения на общем ресурсе сервера и запускается с сервера на локальном ПК или сеансе Terminal Services/Citrix. Она не требует никаких прав администратора. Нет никакого процесса установки, кроме перетаскивания ее на общий ресурс сервера. Она имеет цифровую подпись.
Мне сказали, что некоторые ИТ-отделы не любят, когда ex-ы делятся сервером таким образом. Что я могу сделать, чтобы помочь объяснить ИТ-отделам, что моя утилита безвредна.
Добавлен
Я разработчик инструмента,Автоматическое обновление FE, и он намеренно разработан так, чтобы не требовать привилегий администратора. Это автономный exe-файл без зависимостей установки, кроме нескольких файлов конфигурации (INI), созданных разработчиком с помощью инструмента.
Этот инструмент запускается пользователями на короткие промежутки времени, пока он проверяет, есть ли какие-либо обновления в базе данных Access front end и связанных файлах на сервере. Разработчик, использующий инструмент, может запустить его на две или пять минут, обновляя настройки.
решение1
Вот несколько причин, почему яне нравитсяненавижу запуск исполняемых файлов по сети:
- Клиентские блокировки не позволяют обновлять инструмент до тех пор, пока не наступит момент, когда никто не будет выполнять файл. Это исключает концепцию обновления по требованию с точки зрения пользователя
- Перезагрузка сервера становится необходимой в некоторых случаях, когда возникают зависшие блокировки из-за отключения клиента от сети или завершения процесса.
- Дополнительные накладные расходы на полосу пропускания для сети
- Дополнительное время загрузки для клиента, которое часто проявляется в виде воспринимаемой медленной сети
РЕДАКТИРОВАТЬ:
Ваша дополнительная информация делает это еще хуже! Теперь есть другие внешние зависимости, которые добавляют еще больше риска неудачи.
ПРАВКА 2
Независимо от того, что происходит в процессах, лучше всего запускать их с локального диска. За более чем 15 лет работы в сфере ИТ я не видел ни одного процесса, где преимущество запуска через сетевой ресурс перевешивало бы перечисленные мной риски. (Я оговорюсь, что это происходит в стандартной среде рабочей станции Windows / файлового сервера; у меня нет опыта работы с *nix, чтобы утверждать это там).
Что касается ваших вызовов стандартных API Windows, то это все хорошо и хорошо. Да, они сами по себе довольно стабильны. Добавление Access в микс открывает больше. Но процесс все еще запускается по сети, и риски, о которых я и другие уже упоминали, все еще применимы. Маленький процесс все еще остается процессом, и он все еще уязвим для нестабильности. Просто не стоит останавливать весь сервер, когда один клиентский процесс выходит из строя, если этого можно избежать, переместив двоичные файлы локально на клиент.
Да, меньшие процессы, которые имеют более короткий жизненный цикл, имеют меньший риск отказа и, таким образом, меньший риск возникновения плохих вещей, которые мы описали. Я довольно консервативен в своих административных убеждениях, однако, поэтому я не хотел бы видеть это в своей среде. И, возможно, это нормально в вашей среде, я не знаю.
решение2
Существует множество причин, по которым администратор предпочел бы не размещать исполняемые файлы в сети, как перечислили другие.
What can I do to help explain to IT departments that my utility is benign
Ничего. Их политика установлена, и вы, как посторонний человек, не можете ее контролировать, если только кто-то достаточно важный в компаниипотребности(илиДействительнохочет) ваше программное обеспечение в сети.
решение3
Несмотря на то, что я чувствую к своему бывшемукашель, я не хочу видеть ее казненной, и я администратор.
Тем не менее, вы не предоставили нам достаточно подробной информации, поэтому мне придется сделать несколько предположений.
Я не могу сказать вам конкретно, почему некоторые администраторы не любят .exe на своих общих ресурсах. Могут быть проблемы с установкой, когда вы запускаете исполняемые файлы с общих ресурсов сервера, например. Вы также делаете довольно большое предположение, что ваш исполняемый файл не требует никаких прав администратора для запуска. Откуда вы знаете?
Я скажу вам, что если вы занимаетесь продажей программ, по крайней мере в среде Windows, гораздо удобнее для администраторов распространять свои программы в формате msi. Я не могу себе представить, чтобы у них были сомнения по поводу наличия msi на их серверах.
Обновлено для добавления:
Тони, со временем ты обнаружишь, если ты еще этого не сделал, что все больше и больше сред ощущают необходимость в блокировке. Законно это или нет, в наше время это просто имеет смысл сделать. Хотя время, вложенное в то, чтобы сделать вашу программу максимально податливой к такому сценарию, может быть отличным, я верю, что это принесет ОГРОМНУЮ выгоду в долгосрочной перспективе (в то время как попытки держать системного администратора ВНЕ РУКИ не принесут).
Системные администраторы не занимаются тем, чтобы мешать людям делать свою работу. Совсем наоборот. Если есть кто-то, кого вы хотели бы иметь в качестве друга по ту сторону звонка в техподдержку, так это системный администратор, пытающийся заставить ваше программное обеспечение работать. Сделать так, чтобы ваше программное обеспечение было проще для развертывания и обновления для него/нее, — это то, чего вы хотите.
решение4
Лично я не разрешаю "удалённые" exe-файлы, потому что если бы я это разрешил, то пользователи могли бы загружать всё, что не требует установщика, и запускать это в сети. Не круто с точки зрения безопасности - я разрешаю приложениям выполняться только из "C", а у пользователя есть права на чтение и выполнение для "C".