Hi, I've watched .TMP files being created on machines over VPN since the above patch was applied. The .TMP files are created as part of the write back to the network when a file is edited, however it's not completing the process and still leaves the original documents on the Windows 7 machine in the CSC. The above patch was designed to resolve this, and I'd roughly say it has for the majority, but I'm still getting cases of this when users are on slow connections. Anyone else having this issue still?

Hi, Thanks for posting at Microsoft TechNet forums. According to your description, I suspect that the file has not synchronized to the server so that this happens. Please start the sync manually in the Sync Center for a test. Also, I would like to conirm if you can connect to the remote Lan properly after connecting with VPN. If you have further question about this, please do not hesitate to let me know. Hope this helps. Regards, Juke TechNet Subscriber support in form. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, thanks for your reply. I've notice this happen on our LAN now too. For the VPN user, this was the first time he'd opened the file. Due to slow link detection (I'm guessing) when he opened the file, it was written to the CSC. However the error only occured when he clicked save, as soon as he clicked save, the TMP file appeared. After I watched this happen, I talked the user through opening sync centre, and this file was listed as conflicting, so it will not auto resolve. Checked options to resolve and pushed the file back to the server. For the user that was on the network, there is no indication in Application and Service Logs>Microsoft>Windows>Offline Files that the machine had transitioned to Slow Link mode, the user was completely unaware of Offline Files, yet the machine must have cached the file as she worked on it. Again, when she saved, the TMP file was created and the original document was gone. I have arranged to try and catch this happening before the file is accessed, to see whether it's deleted as it's opened, or deleted as it's saved. Is the TMP file just the original renamed then corrupted, or is the file being deleted from the server and replaced? Either way, it seems to still be a problem, leaving files stuck on machines, and not backed up. Luckily, this is spotted fast for these two users because the files are opened by many people or a fairly regular basis. But in the case of other files, which are only opened by one person for instance, these files could sit in the CSC, and if people aren't aware of this automatic caching, therefore do not check their Sync Centre, these files are never backed up and people could lose potentially months of work if they lose the HD, because as far as they're concerned, these files appear on the network and therefore safe. I know, user education to a degree here - but there is a fault here.

I've attempted to recreate this problem over VPN. We've disabled Slow Link Detection, so the machine is running very very slowly as a result of folder redirection on his desktop etc, but it allowed me to see what is happening during the save process. Opens the file, a ~Docname.xlsx appears, 0 bytes. When he updates the spreadsheet and clicks save, a temp file is created. Soon after, a further temp file is created, and then the original document dissapears. After this, in this case, the original document reappears. So in this instance, it did not fail. I'll need to retest this in the near future, to see if I can see which stage it is failing at or whether Slow Link Detection has had an impact (other than terrible speed over VPN).

Hi, How is going? Regards, Juke TechNet Subscriber support in form. If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Well, Slow Link Detection has been disabled on site... A knee-jerk to another issue we're having... And the problem still exists. It does seem to be tied to slow links, but not slow link detection. This isn't definate, but twice now the problem has occured over VPN, and around tewenty times in one department that are really struggling with access times to a large Network directory. I'm unsure what to do next on this; We cannot shift all the data stored on these older servers(2003 and 2000) to 2008 boxes as yet, due to the need for a defrag on the SAN Storage connected to these servers. (we're running through a clear up exercise to get enough space back to defrag the disks...) I'm guessing that the problem will dissapear when we do move to 2008 back end, and the drives are hardly fragmented.

Hi, If you have already disabled the Slow Link Detection, you will work online when the VPN is established. Based on my experience, this is nothing to do with the Offline files. The behavior that Excel file will create the TMP file may depend on the principle of Office. What is the Sync conflict when the Slow Link Detection is enabled?Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi Juke, From memory, the sync conflict when slow link is enabled, is along the lines of "this file has been deleted from the network" Delete this version or keep it and copy back to the other location. So essentially, the client thinks the file is missing, and has no connection held to the .tmp file created. Sorry to ask a stupid question, but what do you mean by Principle of Office?

Hi, I mean that the Office would create the TMP file when it opens a file. You may refer to the following link. http://support.microsoft.com/kb/211632 Regards, Juke TechNet Subscriber support in form. If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

Hiya, Ah ok, I understand this, the problem we have isn't ~office.tmp files, and it's not their creation on opening. That part works as it should. The problem only comes during a save operation to the network location. It during the process of writing back information to a file, It creates a tmp file named something like 43D435D4.TMP, then changes that name (deleting or possibly renaming the original working .doc at this point) then fails, so only a corrupt version of the original Document is left named similar to the above. After that, the only working copy is that which is left in the sync centre.

Hi Neil, My name is Scott. I'm from Microsoft email support team. For the issue, it is difficult to troubleshoot the root cause of it based on the current information. We may have to capture network trace and MPS report on both the client side and server side, then analyize it to determine the root cause. I am afraid that your issue falls into the paid support category which requires a more in-depth level of support. Please visit the below link to see the various paid support options that are available to better meet your needs. http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone Regards, Scott