Unable to add source domain service account to target QMMAD RUM server - as result, access is denied writing log

Hello Smart People!

I am setting up a migration (prem - prem AD) and hit a brand new issue after using this tool many times. I have an AD issue where I am unable to add the source service account to the migration server's local admin group (in the target) due to an AD issue that is being investigated separately. As a result I am unable to write back logs to the migration server's share (this is not a DNS issue, note the error is access is denied - after successfully finding the server share)

Funny this worked fine after we configured the DNS interop and the trust, but then stopped working 2 days later with no related changes made that I am aware of. I am also (now) unable to add source users to target NTFS ACL's or target domain local groups. (not a real big in its self as the source is being retired right after we move the resources) but cannot do that with this error present.

5/31/2024 10:28:14 AM 8092        Warning: Log path \\QMM_MigServer\QuestResourceUpdatingLogs$\ is not accessible. Error 0x0000052E. The user name or password is incorrect. .
5/31/2024 10:28:14 AM 8092        Warning: Configuration path \\QMM_MigServer\QuestResourceUpdatingConfigs$\ is not accessible. Error 0x0000052E. The user name or password is incorrect. .
5/31/2024 10:28:14 AM 8092        Warning: The Quest Migration Manager RUM Controller Service is not accessible. Error 0x00000005. Access is denied. .

I did try the workaround of creating a local server user account with the same username/pass as the source domain service account but that fails due to advanced security settings in the domain and server. (which I have been unable to change)

Can I change the RUM agent's default log and cfg path to a source domain share for RUM? Not seeing a way to do that via INI or reg settings.(do see a way to change the platform server, but only have the one)

Or does anyone have any other ideas on how to defeat this issue, pending a real AD level fix being deployed? (aside from moving the whole server to the source which is an issue due to lack of a hosting platform or server)

I am asking because MS has not been helpful in resolving this issue and we are under a tight timeline on this project.

Thanks for any ideas!

Update - MS found a code bug from a jan 11 update that they think is the root cause (exception calling FindOne with 0 arguments), no fix after a week since they identified the issue. I moved the server to the source directory and now the client can connect to the migration server in all required ways.