This content has been marked as final. Show 3 replies
Which version of Protect are you currently using? Where is the patch directory hosted (this will be the 'Patch download directory' identified under the 'Patch Downloads' tab within the 'Tools>Options' menu)? It could be that the local machine account does not have permissions to the patch directory.
If all else fails, contacting support directly will allow us the option of obtaining and analyzing log files, which will likely provide more insight.
Sorry for the late reply. I'm only at this client once a week. Also, I don't think I received an email alert from the forum when your reply was posted.
We're on v7.6.0, build 1496. I think that is the latest.
The Patch download directory is in the default location: C:ProgramDataShavlik TechnologiesNetChkPatches
It was not a permission problem with the machine account - the Test Connection button returns Success, and it works against the same directory when not specifying the path via DFS, but via the server name directly.
My theory is this: the dfs path looks like \DomainNameDfsAppsPatches. The first thing that Shavlik tries when you click on File Status Report or Synchronize Download Center is to assume that \DomainName is a server name, and then proceeds to attempt to connect to it. Well, in the case of a domain dfs root, the UNC path is not in the form of \ServerNameShareName, and the program cannot assume that the first part is a server name.
My workaround: I hardcoded the local DfsApps replica in the field 'Unc path' under 'Console connection to distribution server' section, i.e. \ServerNameAppsPatches. I left the Dfs path as is for the Target machines. Now it all works. Ironically, when I go back to Edit this Distribution Server entry, it again displays the Dfs path for both UNC path fields. But on the screen that shows the list of Distribution Servers in table format, the Console Path reads \ServerNameAppsPatches, and not the Dfs path.
You might want to put in a ticket for the developers to fix this inconsistent connection and display behaviour for other customers in a future patch. We're good with the workaround for now.