Can Not Save File - Drawing Open in Another Session

Yup... that's a big part of the rub. I've literally been working like this for over 5 years, and I still mess it up occasionally. And these guys can't figure out how to read the standards manuals I emailed to them.

You just can't find good help these days I guess.

Wow - y'all have been busy. Haha

No, DWL comments have nothing to do with the issue at hand (for me then, or NG1/2 now), which RK demonstrated.

The root of the underlying issue is Kerboros authentication within the domain, due to a slight? time mis-match.. And that's with my being +/- 75 FT from the DC (Domain Controller).

Given the scope of your company, having resources in different locations, you likely have more knowledgeable IT than I am as our entire IT department here (I only have MTA Server, but blew through it kind of bored; just no time to go take the MCSA/MCSE *shrugs*). Once I fixed the time server issue via NETLOGON script, and re-synced my workstation, the issue was gone like snapping your fingers. Walla, Magic.

You mentioned that your servers are being replicated - presumably this is happening so that your local server nodes are acting as local cache for your primary data store, and also configured in a failover cluster, where if the local server goes down, or intentionally taken offline, you're subsequently working off of the secondary (failover) server, and never notice that a failover has happened (save some lag depending on how far away, and what direct bandwidth connectivity you have to same).

That said, at least using Microsoft Server 2012 R2, all of this functionality *should* done in a way that precludes any impact on the users connecting to the local server - as example, my users connect to our local, primary server (Hyper-V virtual DC/File Server/Print Server, etc.) via one specific NIC (the host physical server has a quad-NIC card). My on-premise Exchange server, and RDSH (Terminal) servers are also virtual servers, and have their own NIC assigned, which leaves me the fourth NIC to the physical server host, which is where the replication is done, so as to not affect the user's bandwidth to data their working with. This is all possible, as a failover cluster is Hyper-V-aware, meaning it quietly syncs from VHDx to VHDx (the 'file' used to actually load/run the virtual machines).

Also, not being sure of what your corporate IT policy allows, but your NG2 in Arkansas would get better performance using RDP from his home machine to either a physical, or virtual machine at the closest physical server. If RDP is not permited, then perhaps get IT to consider changing from an IPv4 scope, to using Direct Access, which is inherently dependent on IPv6 scope, but has many benefits over IPv4 VPN tunneling, despite itself (Direct Access) using VPN/IPSEC, it just does so when the machine activates, even before user logs in, and 'instantly' establishes the necessary secure tunnels to shared drives, etc. Direct Access also allows for IT to manage associated systems from anywhere in the world, making it easier to roll out updates, and maintain an even playing field for all employees, no matter where they are.

As for shared projects located in different cities/states, which *may* come up for you, you'll get substantially better performance simply mapping drives to the other server and both working on the same data, rather than having it all sync back and forth - a couple of years ago, I left a large international firm that did this, and it worked beautifully (errr... better than syncing local cached data for shared files due to delays even with instant sync), across states, and even countries.

HTH

Have you checked for the presence of .DWL and .DWL2 files in the location the NG is saving to?

.DWL is a drawing lock file. It should be automatically deleted when the drawing is closed.

No, DWL and DWL2 files are not lock files. File locking has been handled exclusively by the O/S on all Windows versions of AutoCAD.

Those files are simply used by "whohas.arx" to report who last opened the file. You are correct that they should go away when the drawing is properly closed.

Thank you for the correction.

@RK: Yeah, I saw your last post on this issue when BB had it on the other forums.

@BB: Your reply is largely over my head. But I think it's time to go back to the IT guys and take them some of these thoughts. It's obviously not AC. And anything network related is above my pay grade. Unless it has to do with VoIP protocols, I get super lost.

Neither of them have problems when NOT saving to the server.

Okay, when you save an AutoCAD drawing, the following takes place.

1. AutoCAD writes the contents of the editor to a .TMP file in the same location as the .DWG. (for example: sav8c.tmp)

2. The existing .BAK file is deleted.

3. The existing .DWG is renamed to .BAK

4. The .TMP file that was just created is renamed to .DWG

Now this all normally happens pretty fast, especially if the file is small. Maybe 1/2 second, maybe 1 second, or in the case of a large file or slow server, it could take 3,6,10,30, or whatever seconds. Sometimes, if you watch the folder you can see the .TMP flash up and then vanish.

Okay, so think about all this for a second.

Say that #2 can't happen because the .BAK file is locked (by any means, R/O file attributes, O/S locking, file permissions, etc.) - then #3 and #4 are not going to happen either. The result? You end up with an unchanged BAK and DWG, and a new file, the .TMP.

I'm not going to list out every other possible scenario, but I have seen just about every one of them in person.

Just think logically and trace the problem down. Find out what files cannot be deleted/renamed and why.

Lastly, I wrote a blog post on this with even more detail if you're really interested.... http://cadpanacea.com/wp/?p=1351

@resullins - no worries; most of that was actually intended for your IT folks, as that is the hat I wore in solving this issue for my employer. FWIW, server 'stuff' is a lot simpler than it sounds. Easy money.

The only other thing for them to check, is if they've got any other user accounts in the same AD Security Groups having this issue, as that might indicate the problem GPO (Group Policy Object), or NETLOGON Script. An easy test, is to create the user a new, second AD account from an entirely different template Object (Domain Admin?), and see if that issue persists.

Cheers