Take a look at your Integration Server’s About page (which you can get to from the Integration Server administration web site and clicking on the About link in the top right of the page or by visiting http://server:port/WmRoot/server-environment.dsp directly) and check the value of Current User in the Server Environment section. This is the user context under which Integration Server is running, and therefore is the user that needs to be granted write access to the directory you are trying to write the file to.
And now for some background: when running Integration Server on Windows, you can either run it as a console application (by running server.bat in a cmd.exe process) or as a Windows service.
If you’re running it as a console application, then Integration Server will run under the same user context as the cmd.exe process that started it, which is usually, but not necessarily because you can “run as”, the logged on user.
However, if you are running Integration Server as a Windows service, then the Windows service can be configured to run under a different user context to the logged on user. This user account can be one of the special built-in Windows accounts, such as SYSTEM, or some other local Windows account, or a domain account if the computer is a domain member. You can check the user account the Integration Server Windows service logs on as by opening services.msc, double-clicking on the Integration Server Windows service, and looking at the Log On tab. Generally if you are trying to access network resources (ie. not local), you would need Integration Server to run under a domain user account context.
#webMethods#Integration-Server-and-ESB