The default for
DAT. This means it copies the data (file content itself), the attributes (*H*idden, *S*ystem, *R*ead-only, etc.), and the timestamps. If handing it DATSOU, which includes security ACLs, auditing info, and ownership. This is directly from the documentation, copied over at the wonderful ss64:
/COPY:copyflag[s] : What to COPY (default is /COPY:DAT)
(copyflags : D=Data, A=Attributes, T=Timestamps
S=Security=NTFS ACLs, O=Owner info, U=aUditing info).
/SEC : Copy files with SECurity (equivalent to /COPY:DATS).
/DCOPY:T : Copy Directory Timestamps. ##
/COPYALL : Copy ALL file info (equivalent to /COPY:DATSOU).
/NOCOPY : Copy NO file info (useful with /PURGE).
So why is DATSOU not working for you? That might help us figure out exactly what you are looking for? As you mention, there are some limitations. We ran into a similar wall with directories that did not have inherited permissions, which is the issue you described. You could build your own duct tape solution by parsing out info from SetACL, which is the most ridiculously powerful and dangerous Windows util I have seen. That is a pain in the ass though.
Solution two, pull what is probably an insanely large wim and just apply the thing to a fresh drive with
imagex. There is no rule it has to be a Windows system partition; it can be any arbitrary group of files. I have not tried this, so I am sure others can shoot down this idea from experience.
Solution three, consider DFS replication. If you can keep the old share up, you can use DFS replication to just redirect requests for files on one share UNC path to go to another. I did that successfully recently and it saved me a BUNCH of trouble. I do not know your use case though.