Windows 10 and older machines

[SteveYates]

Bonjour

I am trying to help a local machine shop here in France

They have a VM3 from 2007 and a VF8 from 2017 that currently communicate with an old Windows XP based PC. They wanted a 2nd PC added to the system which I have done but the new machine (Dell workstation running Win10) only sees the VF8 on the network, I cannot access the VM3 apart from being able to ping its address and/or name.
Software versions are:
VF8 100.16.000.1041
VM3 M16.03C

Does anyone have any thoughts/suggestions ?


Thanks for any help

 

[hanermo]

Lots of issues.

The new machine probably uses the new IP stack and the new default encrypted smb credentials - which is why it cannot connect.
The new machine also probably uses different ports for local networking via smb.

It is complex,endless possibilities.
If you can allow remote access (teamviewer), I might fix it, est 0.5 - 1 hour.
Same timezone, in bcn, spain.

 

[gerritv]

If you need to access the VM3 using file explorer from Windows 10 then likely you need to enable SMB1. There are risks to this but if you presently have XP machines those risks are already present in your network.

So to enable SMB1 again on Win 10:
Go to Control Panel > Programs and Features > Turn Windows Features on or off > check the box for "SMB 1.0/CIFS File Sharing Support"

 

[coyoinu]

the older machine you'll have to enable networking through the parameters page. You'll probably need to be in DEBUG mode first (setting 7=1, type "DEBUG" in the alarms page, then WRITE)

 

[bryan_machine]

I fixed an issue with a machine using Gerritv's fix - that would be one of the first things I would try for a machine tool that will talk to XP but not to Win10.

 

[SteveYates]

SMB 1.0 is turned on.

Thanks but SMB 1.0 support is already turned on

 

[SteveYates]

The other PC (WinXP) can already see the older machine so networking is turned on

 

[magno_grail]

Windoz 10 has a lot more security features and turned on by default. Go to the network connections and right-click on the device and go down to "Properties". Compare those with the XP machine.
If you download an executable on a Windoz 10 machine it marks it as untrusted will not let it run unless you change it in the Security section of Properties.

 

[bryan_machine]

OK, this is hopefully obvious but maybe not.

SMB 1.0 is *OFF* by default in WIN 10. (Not on the machine tool side, on the win 10 side) - hence winxp will happily talk to your SMB 1.0 machine tool but win10 will refuse, until you override it and force smb 1.0 *ON* on the win10 machine.

(If that's clear and you have already done that, forgive me.)

 

[richardsimpson]

Have you found a solution?

 

[Areo Defense]

@SteveYates
Instead of looking at it from a IT Admin perspective, how about brute force solutions? I am a manufacturing engineer but at my old position I was an assistant IT manager along side my cnc programming/project management duties. We had some older machines which were problematic on a modern network domain; an ancient VF that dropped off after we rolled out new domain servers. On that machine we simply set it up so it was sharing it's folder so a PC could drop files into it directly. Not the most elegant solution but it worked. Later, we purchased a number of Makino wedm's which were problematic as well. The current solution was to simply put external drives on the network and all the old machines saw it on the network, no problems. If you're concerned about file intermingling between cells/machine types/departments/security/reliability, simply connect more drives at will. That method is currently our standard solution with older machines that have networking issues. It's very frustrating that machine tools are shipped with is what essentially a snapshot of current technology but computer operating systems never stop evolving so eventually there are always issues like this. I enjoyed helping to manage our domain and clients but I don't miss it, lol.

As Windows Server and Windows client PC's move along, Microsoft keeps adding more security and keeps upping trust connections in a domain, PC's without the right trust credentials are not allowed access to anything. So far the external drive solution has been bullet proof but I envision a day when servers control routing hardware so even dumb nodes will not be allowed on a network.

 

[hanermo]

The problem is not simply smb.
About 6-8 years ago ms chose to change the encryption on the passwords used on smb ..
This was not communicated to the users !

So most windows machines could not connect to any smb shares -- no way -- until they got a sw patch to upgrade the encryption ..
and of course the sw patch required a lot of other mandatory sw patches which then broke other sw.

Madness !
And it took me about 30 hours of work to discover the root cause, in a ms technical bulletin.
The error msg "access denied" is not exactly helpful .. and the registry logs were not any more helpful either.
There were about 5-6 machines down .. out of 12.

AFTER changing the smb shares encryption to the new 32 bit iirc version the log-ons worked fine.

It´s easy these days to set up a linux box with smb shares -- and choose whatever level of security you want.
And it will share with whatever machine tool you want ..
... and troubleshooting is very accurate due to proper logging of issues.

I´ll help if someone wants, and or ship a box already preconfigured with their stuff, etc.

Fwiw..
Smb dates back to *long ago* around dos 3.11, when ms networking was an optional extra one could install via 3.5" disks.
Maybe around 1993..
Likewise, until abut 4-6 years ago, windoze had network security that one could penetrate with a bulldozer -- via some admin shares and or not published maintenance shares.