There have been some reports of intermittent issues using MicroStation V8i and later when accessing a DGN and/or DWG files stored on shared network drives using the Windows file sharing protocol SMBv2 or SMBv3.
The SMBv2 network protocol is the default protocol for accessing Windows file shares when the workstation is running Windows Vista or later and the server is running Windows Server 2008 or later. SMBv3 is the default for workstations running Windows 8 with servers running Windows Server 2012.
There are some non-Microsoft servers and devices that support SMBv2 / SMBv3, therefore if you are using a non-Microsoft server or device, please check with that vender for what network protocols it supports.
If you are experiencing a SMBv2 / SMBv3 related issue you may intermittently see one of the following error messages when trying to open or save a DGN or DWG file on a network share:
Opening a file…“Unable to open design file. Please contact your local site administrator or technical support provider for further assistance.”
Opening a file…“[DGN File name] is not in a recognized file format”
Saving a file…“Unable to save design file. Most likely, Network connection was lost. Do you want to Retry?”
If you retry the operation several times it should complete successfully. This should not be confused with a problem specific to the file. If the file doesn’t open or save after several tries, then there may be a problem with the actual file.
SMBv2 / SMBv3 related issues are mostly seen when:
The problem stems from changes Microsoft made to the way file locking and caching work under SMBv2 / SMBv3 causing applications to hold on to files longer than the older SMBv1 (The protocol used by default in Windows XP and Windows Server 2003 and earlier).
Examples workflows that could see the error...
To alleviate this problem, there is a fix in a later MicroStation SS3 build. If you believe you are experiencing the issue described in this tech note please contract Bentley Technical Support. This situation is being further evaluated and investigated to be addressed in future released builds.
Note: When a user tries to save a file and encounters a network lock with a build with the fix the user may see the save operation take up to 15 seconds longer than normal. MicroStation will be unresponsive during this time. If a save operation takes longer than 15 it is likely to see one of the above error messages. This is expected for network environments with large latency.
If you are not able to upgrade MicroStation the workaround is to disable SMBv2 / SMBv3 which will cause Windows to fall back to SMBv1. More information on SMBv2 / SMBv3 and how to disable it can be found at http://support.microsoft.com/kb/2696547
Note: There are also a number of non SMBv2 / SMBv3 related issues that can cause these errors such as Anti-virus scanners, file backup services, VSS. You may want to consider disabling SMBv2 / SMBv3 on a few workstations to see if it improves those users experience before considering a larger change.
Product TechNotes and FAQs
Bentley Technical Support KnowledgeBase
Bentley LEARN Server
Bentley's Technical Support Group requests that you please submit any comments you have on this Wiki article to the "Comments" area below. THANK YOU!
Keywords: SMB SMB2 SMB3
What is the "later Microstation SS3 build" that includes this fix? 357? 459?
Not entirely sure if it is related, but I had this happen to a number of user for some time. After a lot of head scratching, plus trial an error we switched off dgn indexer. Since then, I have had no user complain
Ever since we had our server installed [earlier this year] everyone in our office has been getting the “Unable to save design file. Most likely, Network connection was lost. Do you want to Retry?” error. We have just clicked on the ok button and assumed it was an error within our server, perhaps a communication break down somewhere along the line. The file always seems to save it's self after clicking the ok button. To my knowledge no-one has had any of the other error messages. As it doesn't appear to be REALLY broken [i.e. th file does save after dismissing the error] we have just ignored it.
I can empathize with your frustration... in the 30 years I have been in the computing industry, I have personally experienced a number of situations similar to this, where something that appears to be quite innocuous was changed along the way and resulted in far-reaching impact that was never expected (nor desired) by those who called upon that expected behavior. This is especially true in situations that are not considered "the general norm". Nothing changed in our products to produce this behavior, which is not meant to dismiss the fact or pass-the-buck, it is simply something that (in all our testing) we did not expect nor did it appear as a regression. Upon much closer examination, we discovered that low-level dependencies had changed and made subsequent changes in our products to accommodate those who may be affected by these changes. That is what this article identifies and provides options for.
You seem to be missing the point that it appears to be MicroStation and Microsoft that have caused this problem. We have spent time and money trying to get to the bottom of the problem only to find that it is not our network infrastructure. Where do we send the bill for this?
"If you believe you are experiencing the issue described in this tech note please contract Bentley Technical Support." is one of the various options mentioned in this article's "What to do?" section. There are other options, too, which one you choose to pursue is really up to you.
As I said I contacted support who told me that it was my problem not theirs. Do I open another ST for this. I'm also on the latest SS3 as far as I'm aware.
As noted, "The problem stems from changes Microsoft made to the way file locking and caching work under SMBv2 / SMBv3 causing applications to hold on to files longer than the older SMBv1 (The protocol used by default in Windows XP and Windows Server 2003 and earlier)." AFA "What do I do now??", there are various options identified in this article's "What to do?" section.
I've been getting the Unable to save design changes for months now. I even logged an ST to be told by Tech Support that it is not MicroStation but our network that is at fault. We have tested everything on our network (switches, server network card, patch leads, cabling, etc) to find that it is not that. It's a bit galling to find that it is a software problem after all. I'm running MicroStation v08.11.09.357. What do I do now??