일부 관리자가 서버 공유에서 실행되는 exe를 싫어하는 이유는 무엇입니까?

Question 1

제가 여기에 있는 몇 가지 이유는 다음과 같습니다.~~좋아하지 않는다~~네트워크를 통해 실행되는 실행 파일을 싫어합니다.

클라이언트 잠금은 아무도 파일을 실행하지 않는 시점까지 도구가 업데이트되는 것을 방지합니다. 이는 사용자 관점에서 주문형 업데이트 개념을 제거합니다.
클라이언트가 네트워크에서 떨어지거나 프로세스가 죽어서 매달린 잠금이 발생하는 경우에 따라 서버 재부팅이 필요해집니다.
네트워크에 대한 추가 대역폭 오버헤드
클라이언트에 대한 추가 로드 시간. 이는 종종 느린 네트워크로 인식됩니다.

편집하다:

귀하가 추가한 정보는 상황을 더욱 악화시킵니다! 이제 실패 위험을 더 높이는 다른 외부 종속성이 있습니다.

편집 2

프로세스에서 무슨 일이 일어나고 있는지에 관계없이 가장 좋은 방법은 로컬 디스크에서 실행하는 것입니다. 15년이 넘는 IT 경력 동안 저는 네트워크 공유를 통해 이를 시작함으로써 얻을 수 있는 이점이 제가 나열한 위험보다 더 큰 프로세스를 본 적이 없습니다. (표준 Windows 워크스테이션/파일 서버 환경이라고 말함으로써 이에 대한 자격을 부여하겠습니다. 저는 그곳에서 그런 주장을 할 수 있는 *nix 경험이 없습니다.)

표준 Windows API에 대한 호출에 관한 한 모든 것이 훌륭합니다. 예, 그 자체로는 상당히 안정적입니다. Access를 혼합하면 더 많은 가능성이 열립니다. 그러나 프로세스는 여전히 네트워크를 통해 시작되고 있으며 저와 다른 사람들이 이미 언급한 위험은 여전히 적용됩니다. 작은 프로세스는 여전히 프로세스이며 여전히 불안정하기 쉽습니다. 로컬 바이너리를 클라이언트로 이동하여 피할 수 있다면 하나의 클라이언트 프로세스가 고장 났을 때 전체 서버를 중단시킬 가치가 없습니다.

그렇습니다. 수명이 짧은 소규모 프로세스는 실패할 위험이 적고, 따라서 우리가 설명한 나쁜 일이 발생할 위험도 적습니다. 그러나 나는 내 관리 신념에 있어서 상당히 보수적이므로 내 환경에서 그런 일을 보고 싶지 않습니다. 어쩌면 당신의 환경에서는 괜찮을지도 모르겠습니다.

Answer

제가 여기에 있는 몇 가지 이유는 다음과 같습니다.~~좋아하지 않는다~~네트워크를 통해 실행되는 실행 파일을 싫어합니다.

클라이언트 잠금은 아무도 파일을 실행하지 않는 시점까지 도구가 업데이트되는 것을 방지합니다. 이는 사용자 관점에서 주문형 업데이트 개념을 제거합니다.
클라이언트가 네트워크에서 떨어지거나 프로세스가 죽어서 매달린 잠금이 발생하는 경우에 따라 서버 재부팅이 필요해집니다.
네트워크에 대한 추가 대역폭 오버헤드
클라이언트에 대한 추가 로드 시간. 이는 종종 느린 네트워크로 인식됩니다.

편집하다:

귀하가 추가한 정보는 상황을 더욱 악화시킵니다! 이제 실패 위험을 더 높이는 다른 외부 종속성이 있습니다.

편집 2

프로세스에서 무슨 일이 일어나고 있는지에 관계없이 가장 좋은 방법은 로컬 디스크에서 실행하는 것입니다. 15년이 넘는 IT 경력 동안 저는 네트워크 공유를 통해 이를 시작함으로써 얻을 수 있는 이점이 제가 나열한 위험보다 더 큰 프로세스를 본 적이 없습니다. (표준 Windows 워크스테이션/파일 서버 환경이라고 말함으로써 이에 대한 자격을 부여하겠습니다. 저는 그곳에서 그런 주장을 할 수 있는 *nix 경험이 없습니다.)

표준 Windows API에 대한 호출에 관한 한 모든 것이 훌륭합니다. 예, 그 자체로는 상당히 안정적입니다. Access를 혼합하면 더 많은 가능성이 열립니다. 그러나 프로세스는 여전히 네트워크를 통해 시작되고 있으며 저와 다른 사람들이 이미 언급한 위험은 여전히 적용됩니다. 작은 프로세스는 여전히 프로세스이며 여전히 불안정하기 쉽습니다. 로컬 바이너리를 클라이언트로 이동하여 피할 수 있다면 하나의 클라이언트 프로세스가 고장 났을 때 전체 서버를 중단시킬 가치가 없습니다.

그렇습니다. 수명이 짧은 소규모 프로세스는 실패할 위험이 적고, 따라서 우리가 설명한 나쁜 일이 발생할 위험도 적습니다. 그러나 나는 내 관리 신념에 있어서 상당히 보수적이므로 내 환경에서 그런 일을 보고 싶지 않습니다. 어쩌면 당신의 환경에서는 괜찮을지도 모르겠습니다.

Question 2

다른 사람들이 나열한 것처럼 관리자가 네트워크에 실행 파일을 두지 않는 것을 선호하는 데에는 여러 가지 이유가 있습니다.

What can I do to help explain to IT departments that my utility is benign

아무것도 아님. 그들의 정책은 정해져 있고, 회사 내에서 충분히 중요한 사람이 아니라면 외부인으로서 당신은 이를 통제할 수 없습니다.필요(또는정말원함) 네트워크에 소프트웨어가 있습니다.

Answer

다른 사람들이 나열한 것처럼 관리자가 네트워크에 실행 파일을 두지 않는 것을 선호하는 데에는 여러 가지 이유가 있습니다.

What can I do to help explain to IT departments that my utility is benign

아무것도 아님. 그들의 정책은 정해져 있고, 회사 내에서 충분히 중요한 사람이 아니라면 외부인으로서 당신은 이를 통제할 수 없습니다.필요(또는정말원함) 네트워크에 소프트웨어가 있습니다.

Question 3

전 애인에 대해 어떻게 생각하는지에도 불구하고기침, 나는 그녀가 처형되는 것을 보고 싶지 않으며 나는 관리자입니다.

그럼에도 불구하고 우리에게 많은 배경 지식을 제공하지 않았으므로 몇 가지 가정을 해야 합니다.

일부 관리자가 공유에 있는 .exe를 좋아하지 않는 이유를 구체적으로 설명할 수는 없습니다. 예를 들어 서버 공유에서 실행 파일을 시작할 때 설치 문제가 발생할 수 있습니다. 또한 실행 파일에 관리자 권한 실행이 필요하지 않다고 가정합니다. 당신은 어떻게 알겠습니까?

프로그램을 판매하는 사업을 하고 있다면 적어도 Windows 환경에서는 msi 형식으로 프로그램을 배포하는 것이 관리자에게 훨씬 더 친숙하다는 점을 말씀드리고 싶습니다. 나는 그들이 서버 공유에 msi를 갖는 것에 대해 불만을 가질 것이라고 상상할 수 없습니다.

다음을 추가하도록 업데이트되었습니다.

Tony, 시간이 지나면서 점점 더 많은 환경이 폐쇄되어야 할 필요성을 느끼고 있다는 사실을 알게 될 것입니다. 법적이든 아니든 오늘날에는 그렇게 하는 것이 합리적입니다. 가능한 한 해당 시나리오에 맞게 프로그램을 만드는 데 투자한 시간은 클 수 있지만 장기적으로 보면 엄청난 이점을 제공할 것이라고 믿습니다(시스템 관리자를 루프에서 제외시키려고 노력하면 그렇지 않습니다).

시스템 관리자는 사람들이 업무를 수행하지 못하도록 막는 일을 하지 않습니다. 정반대. 기술 지원 전화를 받을 때 친구로 삼고 싶은 사람이 있다면 소프트웨어를 작동시키려는 시스템 관리자입니다. 귀하의 소프트웨어를 더 쉽게 배포하고 업데이트할 수 있도록 만드는 것이 귀하가 원하는 곳입니다.

Answer