Я предполагаю, что учетные данные, которые запускают приложение на сервере2, не имеют разрешения на запись на сервер3 (при условии, что сервер2 использует UNC-путь для записи в файловую систему на сервере3).
У учетной записи пользователя, которая запускает пул приложений IIS (или если учетные данные назначены вашим приложениям) на сервере Server2, потребуется доступ на запись к общему ресурсу / UNCpath на сервере server3; как правило, это означает, что вы не можете использовать NetworkService.
Если вы измените учетную запись пользователя в IIS на сервере server2, вам нужно будет принять во внимание все подразумеваемые разрешения, которые существующая учетная запись пользователя (при условии NetworkService) имеет на server2.
Включая разрешения для файловой системы, реестра, метабазы и т. Д .; список может быть очень длинным и сложным или коротким и неактуальным (в зависимости от вашей реализации на server1 / server2 / server3).
Для всех моих реализаций мы используем учетные записи пользователей AD, которые обозначены как учетные записи служб; с крайне ограниченными разрешениями на серверах каждое приложение будет иметь свою собственную учетную запись службы, а для любых точек соприкосновения потребуются явные разрешения. Таким образом, учетная запись будет настроена для приложения на сервере Server2, а явные разрешения будут настроены на сервере Server2 для запуска приложения, а разрешения UNC-пути / общего ресурса и NTFS на сервере Server Server3 будут явно применяться для передачи файлов.
Надеюсь, это поможет.