06-18-2013 04:20 AM
Hi,
We have an implementation of Symantec DLO with number of Windows 7 and some XP SP3 workstations that works OK. There are two Windows 8 that at first did not permit DLO agent installation, but after enableing Remote Registry Access, DLO agent was successfully installed. The problem is that DLO agent does not work with normal user logged in. If we login as a user that has administrator priviledges, then DLO agent does work and backups are working.
We did search the KB and tried uninstall and install (from setup.exe, on local machine). We also tried to manualy enter the user into DLO Administrator. Nothing helps.
Any clues?
Best regards,
Vladimir Vucinic
06-18-2013 07:17 AM
Log:
06-19-2013 10:45 PM
1.close the DLO client
then stop all services relating to DLO
then delete the scheduled task associated with DLO.
THEN restart the services
and
then opened the client
it WILL WORK
2. If not work then
Uninstall DLO agent and do a clean install using the Setup.exe
06-26-2013 05:17 AM
No, this did not help us resolve the issue. Thanks Inn_kam.
12-02-2013 12:22 PM
Is there a resolution for this problem?
05-23-2014 04:18 PM
I am running into the same issue.
For us, initially, the agent does run at logon and starts backing up. It's only after a few days, and only on Windows 8 clients, that the backup agent (silently) fails to start at logon. When run manually, we get the error V-138-52224-990.
The log has this:
05/23/14 18:12:09 dloclientu.exe 12672: > client.cpp( 1688 ) -- LANGID == ENU --
05/23/14 18:12:09 dloclientu.exe 12672: > client.cpp( 1932 ) BUILD INFO: Build 75096a 5/23/2014 06:12:09.335PM
05/23/14 18:12:09 dloclientu.exe 8912: E> cachedpassword.cpp( 55 ) CCachedPassword::Load() failed for 02BAB4B8
05/23/14 18:12:09 dloclientu.exe 8912: E> cachedpassword.cpp( 55 ) CCachedPassword::Load() failed for 02BAB4B8
05/23/14 18:12:09 dloclientu.exe 8912: E> client.cpp( 4088 ) error loading database Shebang::Load - no server - The database server name is not specified in registry.
05/23/14 18:12:09 dloclientu.exe 8912: E> Client.h( 1111 ) CClientApp::_HandleError() : displaying error message: Failed to load configuration settings.
05/23/14 18:12:09 dloclientu.exe 8912: E> Client.h( 1128 ) CClientApp::_HandleError() : m_pMainWnd is NOT NULL. using DontShowDlg...
05/23/14 18:12:11 dloclientu.exe 8912: E> Client.h( 1144 ) CClientApp::_HandleError() : error shown. returning.
05/23/14 18:12:11 dloclientu.exe 8912: E> client.cpp( 2543 ) CClinetApp::StartupThread : InitializeDB FAILED result=CC0003DE - THROWING res.
05/23/14 18:12:11 dloclientu.exe 8912: W> client.cpp( 2712 ) CClientApp::StartupThread : Caught param error exception, m_id=CC0003DE, ClientApp::StartupThread.InitializeDB - The database server name is not specified in registry.
05/23/14 18:12:11 dloclientu.exe 12672: E> client.cpp( 2028 ) CClientApp::InitInstance : Initialize FAILED, res=3422553054
05-23-2014 05:23 PM
All,
I think I have identified the root cause of this issue.
Using Sysinternals' Process Monitor and KDiff3, I found out that when running Symantec DLO Agent as administrator (in which case it works), dloclientu.exe reads registry keys from
HKLM\SOFTWARE\Wow6432Node\Symantec\Symantec DLO\Client
and several subkeys, including those that contain the info about the location of the DB and NUDF.
However, when running as standard user (same user account, just not elevated), Windows redirects that registry access to the VirtualStore, e.g.
HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node\Symantec
That node does not exist because the installer ran with administrative privileges and that was not redirected.
So, I exported the registry key HKLM\SOFTWARE\Wow6432Node\Symantec to a .reg file. I then replaced all occurrences of HKLM\SOFTWARE\Wow6432Node with HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node (using a standard text editor). Now, I am able to run the DLO agent normally. I have not been able to confirm if it really runs 100%. There may also be file redirection taking place that doesn't cause the agent to fail, but just causes files not to get backed up.
This does not explain why, for me, on Windows 8, it appears to work for several days after installation and fails suddenly.
Maybe this will help someone else,
SA.
02-27-2018 06:30 AM - edited 02-27-2018 06:31 AM
I have been trying to sort this out for ages. I just stumbled across this post and it has worked a treat for one user. I would like to have this option so it can be more generic, so that I don't have to change it for every user, but this is way, way further than I have gotten before. Many thanks SA.