Hi, Thanks for replying. The reason this guy wrote a blog about SMB2 to the link I pasted was because this web blogger read about an old security flaw in SMB2.... but it wasn't the reason why I needed to disable it.
Ever since Vista came out, this has been a HUGE headache for us. We have written code to even test this problem over the network. It worked fine in win2k, and XP, but as soon as Vista and Windows 7 came, their SMB 2.0 and 2.1 network things have been a constant nightmare for us. Disabling SMB2 finally solved the problem once and for all for us. Before, we had .bat files changing registry settings which only worked on certain builds of Vista. It has been a huge headache for us ever since Vista cam eout. As far as are networking situation, we have one machine hosting a shared folder in Windows, (in our case, \\TBM-SERVER\apps in Windows terms), and about 18 stations have that shared folder mapped in Windows. This seems pretty straight forward... but having read Przemek's reply, I would be very curious to try out these new solutions. Only problem is, I am afraid to ask for help, and I have no idea if they apply to our case as described above. It would be nice to avoid this smb2 stuff completely, ie, not using the .msi I found, and do it as Przemek and Angel pointed out. I read: > then you should switch to HBNETIO. If you want much stronger > data protection and move all index processing to server side then you should > use dedicated RDBMS like LETO or ADS. For me to just "get this working" would probably involve me grepping the Harbour source for about 1-2 hours. If there is something obvious I'm missing, I'm very willing to hear it. Thanks for posting! 2010/3/3 Przemysław Czerpak <dru...@acn.waw.pl> > On Tue, 02 Mar 2010, smu johnson wrote: > > Well we have a ton of people who still use Windows, and because of that > we > > need a Windows solution. > > HBNETIO is platform independent solution. It can be used by stations using > only one platform (i.e. only MS-Windows programs) but it also allow to > safely share DBF tables (with memo and indexes) between program compiled > on different platforms i.e. Linux, FreeBSD, SunOS, MacOSX, DOS, W95, WinXP, > W2K, Win7, OS2 stations using native programs accessing the same files. > It system eliminates file sharing with its all potential synchronization > problems by switching to own TCP/IP protocol dedicate to share Harbour > tables. > > > I am happy to report that after about 30 mins of Googling, I came across > > this page, which solved the problem, if you disable SMB2. > > > http://blogs.msdn.com/robmar/archive/2009/09/23/get-microsoft-fix-it-for-smb2-issue.aspx > > Above fix is for remote hackers attack so it's not related to your problem. > Anyhow as I can see there is a switch to disable SMBv2 protocol and this > may indirectly help to resolve the problem because it's possible that it > can be exploited only when SMBv2 is enabled and some buggy network clients > are used. > Anyhow if you do not want to worry about possible problems which can be > caused by some incompatible network transport layer or unsafe concurrent > file access caused by some speed "optimization (i.e. not synchronized read > ahead caches) then you should switch to HBNETIO. If you want much stronger > data protection and move all index processing to server side then you > should > use dedicated RDBMS like LETO or ADS. If you want to full even logical > protection then you should move your whole application to server side and > leave only user interface on the client side. It's the fastest and the most > safe solution. > > best regards, > Przemek > _______________________________________________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson <smujohn...@gmail.com>
_______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
