I seem to have issues with mapping the drives again…
When I use “map only when unmapped” not all nodes map the drives.
When I use “map always” it sometimes maps the drives, but seems to kill the existing mapping on the next run or with those that did map propery in the past…
I think to have excluded all that I could think of:
double checked correct notation of paths
cleared the windows credential manager to reset old passwords to the LAN and set them again
stopped running possible conflicting .bat scripts (to map the drives) at startup of the slaves
any idea how I can trouble shoot / debug this?
as it’s driving me nuts and have no solid way to make this permanent…
The systems are mostly running windows 7 pro or win 8.1 (here it seems not to create issues)
Is there any indication in the job reports of the mappings being ignored for some reason? I am wondering if it thinks the mapping is already there when it’s not doing them.
Part of the problem may be how Windows drops idle connections after about 15 minutes. The mapping appears to be in place, but it’s actually disconnected. Have a look at this article for some possible workarounds. I think if you disable the idle disconnect and choose “map always” in Deadline, you might have better luck.
the thing is… the problem lies before this all.
I’ve done a close up session with one of the nodes to examine all the options.
There are 2 starting scenario’s :
A. where the drives are mapped (from previous session) but not connected
B. where there are no drives mapped at all
If set to “Only Map if Unmapped”:
The Slave starts without a job: there are no changes to the mapped drives in scenario A and B
The Slave starts with a job directly : In scenario A the drives disappear, in B they never are mapped.
When “Only Map if Unmapped” is deselected:
The Slave starts without a job: there are no changes to the mapped drives in scenario A and B
The Slave starts with a job directly :
In scenario A the drives:
most of the times they disappear
allot of times it only reconnects to one of 2 (the one drive where the files are read from/written to)
sometimes reconnects both mapped drives
It seems that after it actually reconnected the drives in one session, after a machine reboot the next session has the mapped drives removed.
In scenario B they are never mapped.
When not using these features (of any alternative) windows doesn’t always connect the maps drives after a reboot so it doesn’t function.
Using a .bat script at the startup of the machines to reconnect the drives seems most successful but isn’t failure proof either (sometimes the startup sequence is delayed and it doesn’t map the drives in time or at all)
I’ll have a look at the article and disable any auto-idle things from the windows end.
Most successful i think would be for the node to first run the bat script before accepting any new task. But not sure this is an option
WIll check the mapping question… Usually I have the ‘ignore missing maps’ enabled
-------- edit ----
strangely enough… when I disable the “ignore missing maps” it doesn’t give an error when the render starts.
I had disabled the “only map if unmapped”
The first time 8 nodes started in scenario A and mapped only the Z drive (where the textures and output are located).
After a machine reboot 7 out of the 8 nodes had no drive mapped and didn’t mention the texture is missing.
I had this too with a Vray DR session. Here I used the farm to render and only noticed that the mapped drives where broken because some tiles where without mapping. But most likely the missing maps aren’t reported with the DR sessions anyway as it’s internally Vray arranged and not via deadline?
Unfortunately, Windows quite often does a lot of harm in its attempts to think on behalf of the user/admin. I personally find Windows networking to be convoluted compared to the more structured approach taken in other operating systems. But, that’s irrelevant if you have tools that only exist on Windows.
What I might do in this situation is this: This is a rather brute-force approach for when all else fails. Create a script that is run on startup and verifies the mappings and repeatedly tries to re-establish them if they do not exist or they are not connected. The script could have a timeout so that it starts e-mailing alerts after, say, 15 minutes of failed attempts (but still keeps trying). Only after it can successfully read from the mapped drive(s) should it start the Launcher (meaning that Launcher would be set to not automatically start with Windows). I would supplement this with a scheduled task that runs every 15 minutes and double-checks the mappings in the same way.
