Mappnig Network Drives for unattended use
When running Web Connection applications under IIS, you are most likely not loggged in as a specific user and there is no user console active. Instead IIS runs under a system context that is a custom logon that isn't directly bound to user control.
This means if you rely on drive mappings in your applications, drive mappings that you make under your regular user account are not going to be visible in the IIS session directly.
This also means that you have to explicitly map drives. There are a couple of ways of doing this.
Use UNC PathsUNC paths are direct network references to paths on the network. So rather than using mapped drive letters you provide the full network file location.
There are several problems with this approach. First and foremost there's no way to specify login information so if your remote drive requires authentication with username and password this will not work. It'll only work when the network login matches rights on both machines.
Additionally in my experience UNC access to files is often drastically slow than mapped drives. I'm not sure why this happens and in researching I've found lots of conflicting information on this topic. Experiment with both shared and UNC drives and compare performance before making a descision on either approach.
Map your Drives on your application's StartupYou can also map a drive as part of your application's startup process. You'll want to do this as one of the very first things you do before you access any resources that live on the remote drive, preferrably in YourServer::OnInit().
You can use the following helper function:
mapnetworkdrive("i:","\\RASXPS\CDrive","username","password") IF (!IsDir("i:\temp")) && point at some known path or file *** Log this error into the startup trace log (wwTraceLog.txt) this.Trace("i: drive was not mapped...") ENDIF
Use your Machine Policy to create a Startup ScriptWindows supports creating startup scripts that are launched as part of policy. Keep in mind that IIS runs under a system context so typically user context is not loaded (ie. there are no startup and start tasks that fire) so using policy is what's required to ensure when a new user sessions is started that the scripts execute.
To do this:
- Go Edit Group Policy from the Start Menu
- Local Computer Policy/Computer Configuration/Windows Setting/Scripts/Startup
- Create a batch file on disk where all accounts can access it
In the batch file include your NET USE statements:
NET USE i: "\\server\data" "password" /USER:"username" /persistent:yes NET USE h: "\\server\configuration" "password" /USER:"username" /persistent:yes
Note that you may have to include the domain name of the user if you are running on a Windows DOMAIN (ie. "DOMAIN\username").
Comment or report problem with topic