Author Topic: ATMP&&&& files  (Read 6562 times)

0 Members and 1 Guest are viewing this topic.

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
ATMP&&&& files
« on: January 05, 2016, 12:08:15 PM »
A question regarding network and autocad saves/qsaves creating ATMP files instead of saving the actual file.
We seem to be encountering files that appear to save only to actually lose edits or other information due to the
file being saved as an ATMP1234 file. 


Any ideas or suggestions at all regarding cause or cure is appreciated!
Be your Best


Michael Farrell
http://primeservicesglobal.com/

Krushert

  • Seagull
  • Posts: 13679
  • FREE BEER Tomorrow!!
Re: ATMP&&&& files
« Reply #1 on: January 05, 2016, 02:17:41 PM »
Again another prime example of Autodesk not fixing things that are broken.   We should not stand this level poor customer service.  :grinwink: :-P :-D
I + XI = X is true ...  ... if you change your perspective.

I no longer CAD or Model, I just hang out here picking up the empties beer cans

Rob...

  • King Gator
  • Posts: 3824
  • Take a little time to stop and smell the roses.
Re: ATMP&&&& files
« Reply #2 on: January 05, 2016, 02:33:42 PM »
Shhh, your going to get him going.

I don't think it's an AutoCAD problem. I've seen that before and there was a warning that AutoCAD could not save to the assigned file and was saving to the TMP file. If I closed the drawing the edits were lost. If I remember right, saving as a different file was successful, preventing the loss of work. The problem went away after server upgrade.

But don't tell him 'cause he's just going to blame AutoDesk anyway.
CAD Tech

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: ATMP&&&& files
« Reply #3 on: January 05, 2016, 02:38:33 PM »
Shhh, your going to get him going.

I don't think it's an AutoCAD problem. I've seen that before and there was a warning that AutoCAD could not save to the assigned file and was saving to the TMP file. If I closed the drawing the edits were lost. If I remember right, saving as a different file was successful, preventing the loss of work. The problem went away after server upgrade.

But don't tell him 'cause he's just going to blame AutoDesk anyway.

Actually IF I was going to blame autodesk I would have done so already.

I'm suspicious of our network topology, and the level of competency of our contract services for same.
Be your Best


Michael Farrell
http://primeservicesglobal.com/

Krushert

  • Seagull
  • Posts: 13679
  • FREE BEER Tomorrow!!
Re: ATMP&&&& files
« Reply #4 on: January 05, 2016, 03:49:51 PM »
I am just being a malapert in good natured way. 
I + XI = X is true ...  ... if you change your perspective.

I no longer CAD or Model, I just hang out here picking up the empties beer cans

Rob...

  • King Gator
  • Posts: 3824
  • Take a little time to stop and smell the roses.
Re: ATMP&&&& files
« Reply #5 on: January 05, 2016, 05:01:41 PM »
I am just being a malapert in good natured way. 

I think we can put that one in the book of Krushisms. Very good.
CAD Tech

57gmc

  • Bull Frog
  • Posts: 366
Re: ATMP&&&& files
« Reply #6 on: January 05, 2016, 06:26:44 PM »
I just saw this on another forum with a link to here. Does this look familiar?

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: ATMP&&&& files
« Reply #7 on: January 06, 2016, 06:00:32 PM »
The challenge I'm up against is the contract IT people are very reluctant to accept that it IS a network issue.
Even though everything I have read, or researched on the topic suggests that it IS.

So, I'm sort of stuck with an infinite loop on how to get it resolved.
Be your Best


Michael Farrell
http://primeservicesglobal.com/

57gmc

  • Bull Frog
  • Posts: 366
Re: ATMP&&&& files
« Reply #8 on: January 06, 2016, 06:27:51 PM »
Somethin's gotta give. :knuppel2:

If as you stated, its only on network saves and not to the C:\ drive, then you would think that would give them a clue.

BlackBox

  • King Gator
  • Posts: 3770
Re: ATMP&&&& files
« Reply #9 on: January 06, 2016, 07:02:43 PM »
MJF -

I've just gone through this with my employer (on both counts; the 3rd party IT, and the network-related AutoCAD save issues).

Skipping some ranting of my own, and going directly to the AutoCAD saves (or lack thereof)... I have yet to see an instance of this issue be the fault of AutoCAD, counter to what even I suspected.

The issue I just overcame, after weeks of trying to diagnose (albeit part-time here or there, as I do production primarily), wasn't AutoCAD updates, or even network latency (as much as I really wanted to find that it was those who shall not be named, always streaming online radio, even when they leave for lunch [those b@stards!] :lol:)... It was "time" that caused all of the malarkey.

More specifically, the legacy environment I inherited with the firing of our 3rd party IT, included a NETLOGON Script which called NET TIME to sync user's session time (on every machine, client, server, etc.) with our domain's Time Server (also our Domain Controller, File/Print Server, etc.)

So our DC (Domain Controller) was syncing time with itself whenever I or they would log in (before they were fired), and the DC effectively synced time with itself - but being a Hyper-V virtual machine (like any brand of VM) the Server measures time in CPU cycles, just like any physical machine - problem is, a VM shutsdown, restarts, etc. and isn't measuring CPU cycles during those times, so little by little, time 'slips'.

Servers generally, and Kerberos (authentication) allow for some difference, but changing any Server 2008 R2 or newer Windows Server to use Windows Time Service (W32TM /RESYNC) in lieu of NET TIME, forces the machine - client, or server - to sync with external Time Server instead (if not the Hyper-V host).

[Edit] - There are a few different ways to implement W32TM; some useful information can be found here: http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-in-hyper-v.aspx

That small change to our startup script for the domain, rectified the issue for everyone here... The only time I've experienced this same issue since, is when our File Server had some critical Windows Updates that were either not yet installed, or failed to install properly (requiring reinstall).

HTH
« Last Edit: January 06, 2016, 08:41:59 PM by BlackBox »
"How we think determines what we do, and what we do determines what we get."

kdub_nz

  • Mesozoic keyThumper
  • SuperMod
  • Water Moccasin
  • Posts: 2148
  • class keyThumper<T>:ILazy<T>
Re: ATMP&&&& files
« Reply #10 on: January 06, 2016, 07:06:19 PM »

most excellent response !!
Called Kerry in my other life
Retired; but they dragged me back in !

I live at UTC + 13.00

---
some people complain about loading the dishwasher.
Sometimes the question is more important than the answer.

BlackBox

  • King Gator
  • Posts: 3770
Re: ATMP&&&& files
« Reply #11 on: January 07, 2016, 03:15:36 PM »

most excellent response !!

Thank you, Kerry; that is kind of you to say. :-)



... Now let's just hope that I'm not entirely wrong as to the cause of Michael's issue. :2funny:

Cheers
"How we think determines what we do, and what we do determines what we get."

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: ATMP&&&& files
« Reply #12 on: January 07, 2016, 04:27:58 PM »
MJF -

I've just gone through this with my employer (on both counts; the 3rd party IT, and the network-related AutoCAD save issues).

Skipping some ranting of my own, and going directly to the AutoCAD saves (or lack thereof)... I have yet to see an instance of this issue be the fault of AutoCAD, counter to what even I suspected.

The issue I just overcame, after weeks of trying to diagnose (albeit part-time here or there, as I do production primarily), wasn't AutoCAD updates, or even network latency (as much as I really wanted to find that it was those who shall not be named, always streaming online radio, even when they leave for lunch [those b@stards!] :lol:)... It was "time" that caused all of the malarkey.

More specifically, the legacy environment I inherited with the firing of our 3rd party IT, included a NETLOGON Script which called NET TIME to sync user's session time (on every machine, client, server, etc.) with our domain's Time Server (also our Domain Controller, File/Print Server, etc.)

So our DC (Domain Controller) was syncing time with itself whenever I or they would log in (before they were fired), and the DC effectively synced time with itself - but being a Hyper-V virtual machine (like any brand of VM) the Server measures time in CPU cycles, just like any physical machine - problem is, a VM shutsdown, restarts, etc. and isn't measuring CPU cycles during those times, so little by little, time 'slips'.

Servers generally, and Kerberos (authentication) allow for some difference, but changing any Server 2008 R2 or newer Windows Server to use Windows Time Service (W32TM /RESYNC) in lieu of NET TIME, forces the machine - client, or server - to sync with external Time Server instead (if not the Hyper-V host).

[Edit] - There are a few different ways to implement W32TM; some useful information can be found here: http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/11/19/time-synchronization-in-hyper-v.aspx

That small change to our startup script for the domain, rectified the issue for everyone here... The only time I've experienced this same issue since, is when our File Server had some critical Windows Updates that were either not yet installed, or failed to install properly (requiring reinstall).

HTH
Thanks for all of this....

At this juncture I am attempting to compile all relevant information, to present to others, such that external IT can be moved off of their inertia, and to stop 
chanting their manta 'the network is performing OK'.  If this is OK then we need to use some other metric to measure acceptable performance, both of the
network and their support staff.

Also I need a good way to somehow get more detailed reporting from them to management about what they do, when they do it, and WHY?
As it seems that far too often stuff thing changes, and other stuff stops working, and the response from them is 'we changed some settings and everything is fine now'.
Leaving me wondering what or why did they change that CAUSED the problem to appear in the first place?  And why should we be paying for support services
for problems that they seem to be causing without us asking for them?
Be your Best


Michael Farrell
http://primeservicesglobal.com/

BlackBox

  • King Gator
  • Posts: 3770
Re: ATMP&&&& files
« Reply #13 on: January 08, 2016, 02:29:28 AM »
We went through something similar.

What I came to realize after being hired on, is that we had a 3rd party IT firm monitoring our entire network, clients, servers, infrastructure, and security appliances. Problem was nobody in-house had 'peer' level access; said more accurately, only owners had access, but no idea what to do with it.

Worse, nobody understood why that was a problem.

Once I took the time to explain some of the be fits for having someone in-house, I had their support, without which there is no point; just let it go, or move on.

3rd party IT required the owner formally request my being granted access (expected, and perfectly reasonable), but owner not knowing much about IT generally, simply asked for me to be granted 'admin access', which was misinterpreted/misstated to mean Domain admin.

What they needed to request, is Enterprise Admin access, which is a completely different scope within your Domain/Forest. Up to you, but might be worthwhile to request a second (elevated) Active Directory account rather than being granted access using your primary user account.

Don't forget to have them provide complete, and accurate documentation of your entire physical and virtual network - ISP, firewall/security appliance, switch, servers (P/V), backup battery (mine's equipped for email notifications, etc), external & virtual server backups, client images, workstation setup checklists for each employee role, wireless access points, as well as printers, group policy, etc. Visio is most commonly used in my experience.

Be sure to check for documentation on any/all instances of SNMP agents, CIM agents, RDSH, Direct Access, SSL, CALs, DNS Scope for IPv4/IPv6, web-based spam filters, on-premise/online Edchange Servers, hybrid on-premise & online Exchange Servers, Autodesk/Transoft, etc.

If you use Office 365, then you also need Admin access to that, unless you're setup for Active Directory Sync.

While you're at it, have them setup Remote Adminitration Tools on your workstation, and install Client Hyper-V if you have any Virtual servers.

Don't forget passwords; you need a document store for each-and-every account and password - procurement accounts, remote monitoring (agents), security appliance, client security software (Trend?) which offen has a client password to 'disable' and an admin password to 'manage'.

Along with SNMP/CIM agents, you should see what (custom?) firewall services they've implemented, and ports they've opened.

I'll leave myriad other topics alone, such as IIS/Web/FTP, PowerShell ISE, VDI, etc.

The point of all of this, is that if, or when the time comes where you're going to pull the lever on terminating 3rd party IT, you need to know what is in place to remove access for them, and change passwords. #KillSwith

HTH
"How we think determines what we do, and what we do determines what we get."

mjfarrell

  • Seagull
  • Posts: 14444
  • Every Student their own Lesson
Re: ATMP&&&& files
« Reply #14 on: January 08, 2016, 08:44:02 AM »
workstation setup checklists for each employee role

ha ha ha ha ha ....

They do not seem to use any such level of organisation!


And there are some other issue that will most likely get in the way of attempting to decouple them from performing our IT support,
as they also serve some role in continuing software development for a proprietary application that we use/sell. 

So any leverage to pry them out would need to be substantial....

Further there is a story of a long and torturous path that eventually led them to employ them, so management would be very hard to convince
that I need to have an active role in 'administering' or even have that level of access to our network.
Frustrating, however a lesson in acceptance.
Be your Best


Michael Farrell
http://primeservicesglobal.com/