We have been having an issue with one particular document library.  The library was created over a year ago, and only recently have we started to use it extensively.

Our team of 15+ people are using SharePoint Workspace to allow them to work offline - this is essential, as we are intending to move from Dropbox and need to have the same functionality here.  I was able to copy the existing documents over from Dropbox to SharePoint using the workspace, and had no issues doing this.

However, there have been a few instances where documents have been uploaded into a folder within the library, but then moved into the root after a few minutes (up to 30 minutes sometimes).  Deleting the document and re-uploading often has the same effect.  Sometimes renaming the document and uploading again will work, sometimes it won't.

I've looked through the SharePoint logs and found this -

05/22/2012 12:27:29.07 w3wp.exe (0x1190)                       0x06EC  SharePoint Foundation                 General                                fbv6                Medium               <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><UpdateListItemsWithKnowledge xmlns="http://schemas.microsoft.com/sharepoint/soap/"><listName>{60DBB088-ECEA-46CC-B6ED-92420956313E}</listName><updates><Batch OnError="Continue" PreCalc="TRUE" DateInUtc="TRUE"><Method Cmd="Move" ID="1"><Field Name="ID">5164</Field><Field Name="MoveNewUrl">/library/Document.pdf</Field><Field Name="FileRef">http://sitename/library/folder/subfolder/Document.pdf</Field><Field Name="owshiddenversion">5</Field><Field Name="MetaInfo" Pro...                2ea20ef3-49ab-4327-8ee8-df387fc4884c

It looks like this is the command that is moving the Document.pdf from folder/subfolder into the root.

I can't see any other information relating to this transaction, and I'm not sure if there's another log to look at.  The IIS log has nothing relating to this either. 

I've looked at the few other mentions of this problem on these forums and checked the obvious - there's no workflow in place, there's no event handling or retention policies, and Content Organizer is not activated on this site.

Any ideas?

so, we have time 05/22/2012 12:27:29.07 , and we know the document library name, can you find more information in the SharePoint audit log? or in the RequestUsage view in WSS_Logging database.

Thanks GuYuming, that was helpful.  I've found information in the WSS_Logging database relating to these transactions, and have determined it's not a single user carrying out these operations.  Here's one of the transactions:

MachineName	WFE1
FarmId	6A69A3CD-3EBF-43B3-A7B3-367ED8D066FB
SiteSubscriptionId	00000000-0000-0000-0000-000000000000
UserLogin	domain\user1
CorrelationId	2EA20EF3-49AB-4327-8EE8-DF387FC4884C
WebApplicationId	00000000-0000-0000-0000-000000000000
ServerUrl	http://domainname
SiteId	00000000-0000-0000-0000-000000000000
WebId	00000000-0000-0000-0000-000000000000
DocumentPath	/sitename/_vti_bin/lists.asmx
BytesConsumed	0
HttpStatus	200
Browser	Unknown
UserAgent	Microsoft Office Sharepoint Workspace 2010 (14.0.6112) Windows NT 6.1
UserAddress	[IP address of user's laptop]
RequestCount	1
QueryCount	7
QueryDurationSum	42
ServiceCallCount	0
ServiceCallDurationSum	0
OperationCount	1
Duration	111
RequestType	POST

The other entries I found were pretty much the same, but different users and IP addresses.  Same UserAgent.  I've removed the empty columns.

With Network Monitor and Office SharePoint parser, you can get more.

If you manually move documents in SharePoint workspace, or sync after move, will the Network Monitor capture match the log in SharePoint server side?

I've installed Network Monitor on both web front end servers, and performed a manual sync in my Workspace, and also manually moved a file from the root back to the folder where it belongs.  Using the Network Monitor, I've found the exact transaction and its response.  Other than being able to see the full SOAP request, I don't see any other information that I couldn't gather from WSS_Logging.

I'm reluctant to leave Network Monitor running on the web front end servers, as I understand it can be quite processor-intensive, and there's no way to tell when the move back to root will occur.  I've not used Network Monitor before - is there a way to restrict the monitor (and limit processor use), other than just filtering the results?

And I suppose the other question is, what information am I looking for?

"Network Monitor on both web front end servers"

Just run Network Monitor on the Windows client where your SharePoint workspace runs.

• Marked as answer by GuYumingMicrosoft contingent staff, Moderator Tuesday, May 29, 2012 8:59 AM

Hi,

One of my customers is having the exact same issue, but we've not been able to track down the cause. Did you ever find a resolution to this problem ?  

Many Thanks

/Kelvin

Hi,

One of my customers is having the exact same issue, but we've not been able to track down the cause. Did you ever find a resolution to this problem ?  

Many Thanks

/Kelvin

The "solution" we found was to stop using SharePoint Workspace, basically. These problems weren't happening when only one person was "synced" to a library, and only started happening when multiple users were attempting to sync. So the business moved their sync requirements to Box (and now we're working on OneDrive For Business with SharePoint 2013).