FEI DCOM issue

[Probeman]

Hi John,
Yeah, keeping all these computers updated and backed up is more of a pain than it should be for sure.

I have not heard of a "variance process" but if we keep the computer on a private network they really don't care.  The problem then becomes keeping the anti-virus and backup software licenses updated.

I mention anti-virus because not all viruses come from the Internet, we've had students bring them in on USB sticks.  And some of our Norton Ghost installs need to check for a current subscription or they won't run backups. That's how we killed the DCOM on the Quanta MPC last month.  Next time I try that I will install a separate network card for the campus network to be used temporarily.

More pain will come after next year when the campus will want us to update our Win7 computers to Win10. Fortunately while upgrading from WinXP requires a clean install of Win7 or Win10 and re-installation of all apps, our IT person says that upgrading from Win7 to Win10 is pretty straight forward as the apps will not need to be re-installed. We'll see!  One issue I foresee is the shared folder issue when our Win2K Quanta MPC needs to connect to a computer on the Internet for file sharing due to the SMB v1 vs. SMB v2 issue previously described.

The other issue is that Symantec does not currently have a Ghost backup/recovery version for Win10.  So we're using the built-in Windows backup, but according to our IT person it's non-trivial to utilize Win10 Backup to restore a crashed hard drive- which can be a real life saver in the lab for computers with complex installs of OEM software for instrument operation. 

Hard drives are more reliable than ever, but still Norton Ghost has been utilized several times in the last 5 to 10 years out of a dozen or so computers that I manage.

I've heard about the Win10 update issues, but I haven't been personally affected yet. That said I only have Win10 on one of our file servers and it only needs to run an FTP server. Plus I do have Win10 on my personal laptop, but I only use it when traveling.  Hopefully Microsoft will get its act together before we are forced to update all our workstations from Win7 to Win10 next year.

The best news is that CalcZAF, Probe for EPMA and Probe Image all seem to run fine on Windows 10, so that's a relief at least!

[JonF]

Looks like you might be able to turn smb v1 back on in win 10:

https://support.microsoft.com/en-gb/help/4034314/smbv1-is-not-installed-by-default-in-windows

Or you can fiddle with the smb v2 requirements so that it plays nice with smb v1.

[Probeman]

Looks like you might be able to turn smb v1 back on in win 10:

https://support.microsoft.com/en-gb/help/4034314/smbv1-is-not-installed-by-default-in-windows

Or you can fiddle with the smb v2 requirements so that it plays nice with smb v1.

Holy crap!   

How come my IT person didn't know this?   

Thanks, Jon.

[Probeman]

Looks like you might be able to turn smb v1 back on in win 10:

https://support.microsoft.com/en-gb/help/4034314/smbv1-is-not-installed-by-default-in-windows

Or you can fiddle with the smb v2 requirements so that it plays nice with smb v1.

Our IT guy said that if we turn SMB v1 back on a Windows10 system, the campus will still cut off Internet access to that computer. I don't know exactly how they detect SMB v.1 is available, but I suspect that modifying SMB "so it plays nice with smb v1" would result in the same response from them.

I know, I know, they're just trying to protect us...

[jrminter]

Ned Pile (The "owner" of SMB at Microsoft ) published this explanation of why he thought it was necessary to quit using SMB1: https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/.

The key quote:

The nasty bit is that no matter how you secure all these things, if your clients use SMB1, then a man-in-the-middle can tell your client to ignore all the above. All they need to do is block SMB2+ on themselves and answer to your server’s name or IP. Your client will happily derp away on SMB1 and share all its darkest secrets unless you required encryption on that share to prevent SMB1 in the first place. This is not theoretical – we’ve seen it. We believe this so strongly that when we introduced Scaleout File Server, we explicitly prevented SMB1 access to those shares!

I'm not certain how likely such an attack is, but I see why IT organizations are concered... I don't see any easy answers...

[JonF]

Yeah, I'd guess so. They'll be disabling smb v1 because its got a fairly big security hole, linked to a lot of the more recent ransomware attacks.

Essentially, you've got the Win2k box on the Quanta that can only communicate via smb.v1, a support PC that needs smb.v1 to communicate with the Win2k Quanta PC and a requirement that all university network connected PCs have smb.v1 disabled and a minimum of smb.v2. Bit of a tricky one!

The only way I could think of doing it would require a second support PC (assuming that you can't enable smb.v1 on a per interface basis, which samba in Linux may be able to do), something along the following lines:

Quanta (Win2k)  -smb.v1-> 1st Support PC (Win7,10w/smb.v1/Linux) -smb.v2-> 2nd Support PC (Win10 w/smb.v1 disabled) -smb.v2-> University Network

Both support PCs would need at least two NICs. The first support PC would be able to communicate via both smb.v1 and smb.v2, the 2nd support PC via smb.v2 and above. You could have the data cascading through the support PCs (possibly deleted from the 1st support PC to remove the storage requirement, depending on how you have the data policy configured). You could also make all the shares read only, adding an extra bit of protection. 

To get round the requirement for regular antivirus updates, I'd disable all USB ports (via group policy) and ban USB pen drive access to any of the instrument or support PCs, making everyone pull the data from the network share (whether 2nd support PC or a data store on the university network), and preferably have the 1st support PC as a Linux machine also acting as a hardware firewall. I'd image a working version of the Quanta PC win2k installation, and keep that in a safe place and ensure that all the data that changes is sent off the instrument PC (removing the Norton Ghost requirement).

If going with windows for the support PCs, I'd recommend getting a backup/copy program that supports the volume shadow copy service, or write a script that creates the copy, robocopy to the network share then deletes the shadow copy - this should avoid any issues with locking a file currently having data written to it.

[JonF]

The only way I could think of doing it would require a second support PC (assuming that you can't enable smb.v1 on a per interface basis, which samba in Linux may be able to do), something along the following lines:

I was just googling something else and came across the answer to this: yes, you can bind samba to interfaces under Linux and have multiple instances of samba installed. The SMB settings in Windows are set for the whole OS (rather than NIC specific).

Linux is probably the way I'd go with this - it'll give you more flexibility on the networking side of things. I'd set up a linux server with two physical NICs - one internal to the lab with SMBv1 enabled to talk to the quanta; and one facing the external network with SMBv1 disabled.


A Windows-only alternative would be to run a virtual machine with an SMBv1 enabled guest having access only to the internal NIC and the host OS pushing the data to offsite storage. 

[Probeman]

The only way I could think of doing it would require a second support PC (assuming that you can't enable smb.v1 on a per interface basis, which samba in Linux may be able to do), something along the following lines:

I was just googling something else and came across the answer to this: yes, you can bind samba to interfaces under Linux and have multiple instances of samba installed. The SMB settings in Windows are set for the whole OS (rather than NIC specific).

Linux is probably the way I'd go with this - it'll give you more flexibility on the networking side of things. I'd set up a linux server with two physical NICs - one internal to the lab with SMBv1 enabled to talk to the quanta; and one facing the external network with SMBv1 disabled.


A Windows-only alternative would be to run a virtual machine with an SMBv1 enabled guest having access only to the internal NIC and the host OS pushing the data to offsite storage.

You are smart!   

Seriously, it may come to running a virtual machine as Windows 10 only supports SMBv2. For now we are OK as Windows 7 supports both SMB versions.  But IT tells us that Windows 7 will only be supported until the end of 2019.  Of course I've noticed that Microsoft is still releasing security updates for Windows XP, so maybe it won't happen that fast.

Then one has to consider that Microsoft has been struggling with some recent Windows 10 updates...  Anyway, hopefully by the time we have to update this Windows 7 support computer to Windows 10, we'll get a new FEG SEM with new instrument software and won't have to run Windows 2000!   

Hey, one can always dream, right?

[Probeman]

Today I came into the lab and noticed that the Thermo Pathfinder was not showing the correct mag or stage positions on our FEI Quanta instrument. So of course I re-started Pathfinder because if someone had re-started the FEI software while the Thermo software was running, it will break the DCOM connection. But when the Thermo Pathfinder re-started I got the error "Failed to Connect" and then "Connection Not made".

Now you might ask, why am I posting this in the PictureSnapApp board?  Well, mostly because there is no FEI board on this forum, but also because when I start PictureSnapApp I also get the error "Permission Denied", so it seems the DCOM connection is now broken in general for all apps.

So I re-started the Quanta computer and software, but still no dice. I can ping the Quanta microscope computer at 192.168.0.1 from the Thermp?PSA computer fine, but both PictureSnapApp and Pathfinder refuse to connect to the FEI computer over the local 192.168.0.1 connection.

I should probably also re-start the Thermo/PSA computer but it's in the middle of a Monte Carlo calculation for a paper and I hate to interrupt it. Maybe tomorrow.

In the meantime, does anyone have any suggestions as to why the DCOM connection is suddenly broken, but the user logins for both computers are still the same?

Just an update on the DCOM wars on our FEI Quanta Win 2000 computer...

We finally got the DCOM connection working again, but to be honest we really aren't exactly sure how it happened or what we did to fix the problem!  Yup, not very satisfying, but here's our best guess now that the smoke has cleared:

To begin with we think that the issue started when we temporarily connected the Quanta MPC to the Internet to allow the Norton Ghost software to renew it's subscription. Norton had been complaining that our license had expired so I thought, what's the harm in connecting an Internet cable to the PC?  I'll just change the IP address from static private to a dynamic address on the campus network, then restore the 192.168.0.1 static address afterwards. And we were able to renew the Ghost subscription and then I reset the connection back to it's original values, and was able to ping the computer through the 192.168.0.x subnet afterwards so all seemed fine network wise.

But apparently something was not happy and the DCOM would not connect even though we went through all the many steps provided to us by Thermo and FEI support. We then decided to try and get a duplicate hard disk we had made a few years ago, but for some other reason every time we tried to boot it up, it would get to the Windows 2000 logo and then blue screen.

Our instrument engineer tried everything he could think of but still no dice.  So then we called in the campus IT people to try and help us get the duplicate disk bootable, and so I demonstrated the DCOM problem on the original working disk, and lo and behold, the DCOM connections all worked perfectly!

The only thing we can think of is that somehow in the process of trying to re-boot the computer with a different disk and having to go into the ROM settings we somehow got the network card working properly again.  But who knows?

Jeez, what a pain, but PictureSnapApp and Thermo Pathfinder all seem happy now connecting to the Xt software on the Quanta MPC. I just hope this never happens to anyone else!

Well our PictureSnapApp and Thermo Pathfinder softwares are once again, not connecting to the FEI Quanta software over the DCOM connection from our Win 7 computer.

As you all can see from the above previous post, we got it working a couple of years ago when we started getting this "Permission Denied" error, but aren't quite sure how we fixed it!  I suspect that on the Win XP computer which is running the Quanta software, there is a network setting not allowing the DCOM connection for some reason.

Any suggestions where to look?