SyncBack hang/freeze on Windows 7 - SMB version problem

Problem: SyncBack Free is a brilliant free tool for synchronizing two folders' contents fast and accurate. I had been using a Windows XP computer with two network cards standing as a bridge between two networks to sync folders between two computers residing on each side of the bridge. Old of age the XP computer were looking forward to its retirement as a young Win7 computer were set up to take over its place. The same SyncBack running the same SyncBack profile on the Win7 computer completely hung the SyncBack process within seconds after syncing was attempted. Only a reboot would kill the process - not even Task Manager managed to take it down.

Factors in the picture:

• The two remote computers were running Win7  and Server 2008 R2.
• Syncing between a local folder on the Win7 computer and one of the remote computers would work. Just not syncing between the two remote computers.
• It made no difference whether Windows Shell (on the Copy/Delete tab) was used to sync or not.
• Copying files between the remote computers from Windows explorer works just fine.

Problem reason: The reason proved to be SMB version. WinXP uses SMB 1.0, whileas Win7 uses SMB 2.0. For some reason, SyncBack does not manage to copy files between two remote computers as long as the computer is set up to use SMB 2.0.

Solution: Disable SMB v. 2.0, forcing the Win7 computer to revert to using SMB 1.0. This excellent article on Petri explains how - or here in short: From an administrative command line window run the following commands and then reboot to activate (Observe that "bowser" is actually correctly spelled - or rather, it is spelled the way that the computer understands):

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled

If you need to revert to SMB 2.0, use the following commands:

sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto 

I have not put any effort into researching whether security is an issue with these settings or whether other functionality is negatively affected, for me it gave me what I needed, so I am happy.

DDE on XP/2003

Ever tried porting a DDE app to Windows XP/2003 that you know worked under Windows NT/9x? It just won't communicate. Having found the problem twice and then forgotten again, here's the note on what is (normally) wrong:

The NetDDE services (Control Panel-Administrative Tools-Services) need to be started. Set startup type to automatic (they are disabled by default), and to avoid rebooting the first time, start them as well.

Fileshares: Connecting with the wrong hostname

Situation: Occasionally I need to connect to servers with names formed from a spoon of alphabet soup - impossible to remember. Of course, since the customer is always right, he gets to choose the names of his own server. I however, need to refer to computer names I can remember or that has a meaning.

Workaround: Put an entry in your hosts/lmhosts file (in the c:\windows\system32\drivers\etc folder), or if you have access to the DNS or WINS server, put the entry there, using your preferred name and the IP of the server you want to reach. If, for instance, a server is named something like SA823SX3B and you want to name it FILESERVER, just put in an entry for FILESERVER with the SA823SX3B's IP. It works for ping and many other services, but:

Problem: This does (by default) NOT work if you want to connect to a NetBIOS fileshare. You can verify that firewalls etc. is not the cause of this problem by connecting via \\SA823SX3B\fileshare and even by using \\192.168.0.1\fileshare (given that that's the IP of our example server).

Solution: You need to hack the following registry key on the server in question:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\
DisableStrictNameChecking

Set the value to 1 and reboot. You can now connect to the server using any name you please, as long as it is referring to the right IP address.

Caveat: On a NT4 computer, you will still not be able to connect without using either the real name or the IP address as reference.

See Microsoft KB 281308 for a description of this parameter.