Happens with both Windows Server 20 versions running on the file server.

Weird, indeed, but not that much since it is 100% reproducible. BTW: who could be possibly that insane to ask a customer to reformat three production file servers? Also, it is not a NTFS security permissions problem, because rendering works fine with any mapped drive, as long as they use the first letter available after the local disks and DVD-ROM. And to note: the Adobe guy who provided support asked me to re-format my network shared folders as a solution, which is clearly not the solution, since it happens with different file servers and different workstations. We tried logging a support ticket with Adobe this morning, but had not heard anything from them yet regarding the situation. It has all of the features of a software bug. We tried with three different Active Directory networks and workstations. We do not have a D: drive in our Windows 7 workstations, they are all C: only. Also, simply unmapping F: and leaving G: as the only connected network folder makes render to work. If we remap drive F: to any letter AFTER G:, making G: the first available network drive, rendering works. ODD! If we remap F: drive with a different letter, but a letter BEFORE G:, the problem always happens.

But, when the destination is the G: drive, rendering never works, the error is showed, but a zero-byte file is created in F: (!!).

If we have only two mapped drives, F: and G: for example, and we try to render something to F:, everything works fine and no error is showed. The funny thing: it only happens when there are at least two shared folders mapped on the workstation, and the destination folder used for the rendered movie is not the first one. We're getting the same error when trying to render to Quicktime files using network shared folders as a destination: Windows 7 Professional/Ultimate 64 bits (with and with Service Pack 1) Apple Quicktime 7.6.9 (1680.9) (tried with different versions of Quicktime, since 7.0)

After effects cs5 download windows