To summarise where we are with these problems, I have been experiencing 3 different network related problem.
1) ‘Network Failure’ due to Windows trying to use the Microsoft Account username to log onto the server. This can be worked around by setting SyncBack to use the supplied username and password from the profile.
2) ‘Scan Failure’ again due to Windows trying to use the Microsoft Account username to log onto the server, but reported in the log file as ‘invalid path’. There is no workaround for this problem at the moment.
3) ‘Scan Failure’ due to one profile causing the connection to be disconnected while another profile is still running. This is fixed with the changes in V7.0.11.0 and supplying no username and password in the profile.
The workaround/fix for 1 and 3 are incompatible.
The causes of 1 and 2 may be due to a possible Windows issue but it causes serious issues for SyncBack with a very high frequency of profile failures. It can potential effect any Windows 8.1 when it is configured to login with a Microsoft Account. The following is my further investigations of the issue, it is fairly complex problem so I hope that the description makes some kind of sense.
It appears that the root cause of this problem is that when a process is started by the task schedule with evaluated privileges to run in the user’s session it cannot access the credentials manager (this is the same configuration that SyncBack uses to implements it’s ‘Start with Windows’ option). You can test this by creating a task in the task scheduler to run the following command.
CMD /C "cmdkey /list && pause"
If the task runs with evaluated privileges it will not list any of the stored credentials, however if it is run with normal privileges it will successfully list the credentials (the same is true if you try to read the credentials with a simple program using the CredRead API call). This happens if the task is set to run at login or scheduled, but not if it is run manually from within the task scheduler.
Just to confuse matters if the user interactively does something that causes the any application to run with elevated privileges before the task runs or tries to read the credentials manager then the read from the task will succeed. This can be reproduced by changing the command in the task scheduler to ‘CMD /C "timeout 60 && cmdkey /list && pause"’ and just starting a command window with admin privileges while the task is paused.
I would guess that the process created by the task scheduler cannot load the credentials from disk, but once another process has loaded them and cached them in memory the task scheduler process can then access them. Taking this theory one step further if the credentials are flushed from memory at some point in the future then the problem would reoccur. As I said this is just a guess but it would seem to fit with the problems I have been seeing.
This behaviour can be seen on BOTH Windows 7 and Windows 8.1, whether it is a bug or by design I do not know.
What happens when Windows tries to establish a connection to the server (either automatically as a result of operation specifying a UNC path or by a call to WNetAddConnection2 with a NULL username argument) is that Windows first checks the credential manager to see if it holds the username and password for the server, if it does it uses the stored credentials if not it uses the default username and password. On Windows 7 and Windows 8.1 set to use a local account login the default username is in the form ‘<node>\<local_account>’, on Windows 8.1 set to use the Microsoft Account to login the default is in the form ‘MicrosoftAccount\<live_id>’ (I have confirmed this by deleting the server’s credentials from the credentials manager and then trying to browse the server with Windows explorer). So when the credential manager access fails the wrong username and password is sent to the server and the login will fail.
Matters are further completed by the fact the connections are potentially shared between processes and even different applications, that username names appear to persist within Windows networking and that real connections to the server are not necessary created and destroyed when you call WNetAddConnection2 and WNetCancelConnection2. These factors have the effect of making the problem seem random, good and bad logins can be propagated between different processes or applications.
So this is looking like a generic problem and not system specific issue with my PC and therefore another Windows 8.1, and presumably Windows 8, system using the Microsoft Account to login that also backs up to a server in a workgroup is likely to see this problem. Possibly the way I have my profiles configured and/or my usage pattern on this system may mean that this problem is more visible to me. A user that just happens to run a application with elevated privileges before SyncBack starts to run a backup will be less likely to see this issue, but it is still there.
Even if I knew how to report this issue to Microsoft I cannot see it being fixed in the short term. So it would appear that SyncBack needs to be able to workaround this issue, as I have already stated the current workaround of setting the profile to use the supplied username and password does not completely fix the problem and I still get very frequent profile failures. As I suggested in my previous post getting the username with GetUserNameEx and passing that as the username argument to WNetAddConnection2 would force Windows to use the same default username and password as pervious Windows releases.
Andrew.
![[2bs]](http://www.2brightsparks.com/bb/images/smilies/2bs.gif "2BrightSparks")
