Please consider upgrading the way that Desktop Authority handles a problem with the log share. We migrated DA to a new server. The problem is some of the profiles configured the log location as \\server\logs$$. Others profiles had a variable [LOGFILEsomething]. Profiles that included the server name were a problem. The old server was gone. Every hour the workstation would essentially lock up until this process timed out (bad programming).
If the share doesn't exist, write it to the SLtrace and move on. No need to lock up the workstation for 90 seconds.
The share “Logs$” is used for the Logging Object and not for the SLTrace.htm files. The files that get uploaded to that share are .CSV files and unless you are actively going to the share to view these files most likely they are not being used. So in most cases we can disable logging to prevent any future delays.
In the Desktop Authority Manager:
Repeat these steps for each profile, once completed perform a Replication.
Source: How to disable Logging
In reply to Christopher B:
In reply to jay.griffin:
I just needed to clarify that logging is an older way of reporting and is not tied to the SLTrace file. In most cases when this has come up logging was not being used and is usually disabled. The delay you are seeing is because of a Windows timeout when trying to access UNC path. Explorer will sometimes hang and become slow when trying to access a path that no longer exists.
I agree with you that this can and does cause issues occasionally. We are always looking for suggestions and ideas to make Desktop Authority better. Whenever you see something that you think can be improved or added to Desktop Authority you can post it on our Product Suggestions page. Other users can upvote your suggestion and our Product team reviews the submissions.
We will also review the migration KBs to make sure that editing the logging path is listed in the process.