how to map network drive for Clearcase View in Windows service?

I want to map a clearcase view on network drive inside a windows service.

开发者_高级运维 I have tried with net use command, but it did not work properly.

---

You should be able to run the same kind of command than the one used when paths are too long, which is subst:

subst X: c:\path\to\my\View # for snapshot view
subst X: M:\myView # for dynamic view

in order to map a view to a drive letter.

This should work from within a service, provided:

• you are using your Windows account (and not the "Local System account")
• the dynamic view is already started (and visible in the M:\ MVFS mounting point drive)

---

I wish this approach would work, but it really doesn't from a service; I've beat on this problem pretty intensely to no avail. The problem is two-fold:

1. From a Windows service, to be able to map drives visible to other users it has to "Log on" as the "Local system" account (default) with the "Interact with desktop" property set.
2. To be able to talk to ClearCase, the Windows service process has to "Log on" as a normal user with ClearCase access (e.g. in the atria group typically).

So (1) and (2) are mutually exclusive, but you need to do both and can't. For (2), presumably the reason you can't "Interact with desktop" and map drives there is because you'd need a logon session / token which has to be present for mapped drives to work --associated per-user session--but services need to be able to run headless (no one logged in) where there is no "session" / token that exists.

Note that the way Rational BuildForge solves this for ClearCase is by spawning an entirely new child-process solely to allow its' service to talk to ClearCase:

• https://www-304.ibm.com/support/docview.wss?uid=swg1PK50021

Also note that the "logon session" is identified by a unique token; this means that even if you have a process running as your desired user (domain\fred) that can access ClearCase, spawning a new process from there as the same user (domain\fred) may not have the same session token by default, depending on how it was created (i.e. CreateProcess() vs CreateProcessAsUser() vs CreateProcessWithLogonW()), making it ever more difficult to deal with tools you don't control. To demonstrate this, try running 'runas /user: "cmd /k \"net use\""' from a command prompt and you'll see all your network drives listed as "Unavailable"(!!).

It is possible (though explicitly not recommended by Microsoft), with great effort, to get this all to work if you can somehow manage to have a user always logged in from which to get their session token, as described here:

starting a UAC elevated process from a non-interactive service (win32/.net/powershell)

Otherwise, you'd have to emulate it like BuildForge does.

Also see:

• Network drive is unavailable if mapped by service

• Map a network drive to be used by a service

For this sort of problem I've typically run into it with CI servers (CC.NET / Hudson / TeamCity) that run as a Windows service. What I've had to do is ensure that somewhere before my real "job" was started, I scripted a way to map network drives by re-mapping them at runtime or mapping M:\ to an available drive letter with subst (very tedious) as VonC describes, which isn't persistent (even if you use 'net use /persistent:yes') which is what I'm guessing you were hoping for too.