>>>True. But the typical back-office data entry program I visualize should be able to run on server hosted XP VMs accessed via MSTSC/RDS hitting a XP server backend on a 32GB quad or hexacore on SSD with ease. I BELIEVE you could keep SMB1 broadcasting/vulnerabilities inside the subnet created by virtualization software inside that machine - in practice I would slap a cheap router in front of that machine creating a cascading subnet and only tunnel through via MSTSC ports and special rules, separating that app and XP vulnerabilities from nomal network ;-)
>>
>>Once upon a time, this kind of problems was solved rock solid by having a bare-bones minimal linux box as a file server, and by keeping the tables on a share on it. But that was before SMB2 and I wonder if that solution is still viable. In my environment I have two linux boxes (my main box and a tiny linux mint proto-tablet Acer Aspire, which is about ten years old), plus three W7 boxes (one virtual, hosted in the main box) and I've found that I haven't found it easy to get any networking done. Between W7's mostly yes (machine A to B and back, but B-C and A-C either never or sometimes), linux-to-linux or windows-to-linux no (except the special connection between the VM and its host).
>
>If I'm not mistaken, current versions of Samba on Linux does support SMB2/3 and there are indeed "tweaks" similar to ones you could apply to a Windows server to get around situations that result in corrupt files being used in shared mode.
But the 64K$ question here is whether the windowses-side SMB stack will misreport dirty buffers in this configuration, i.e. whether this is still a solution.