Larry, I went through all of the FTP access tests before when I encountered the issue at the first customer site about a month ago, Everything was normal and we also temporarily cut a lot of the files in the \discovery folder to see if reducing it down to 100 from 10000 would make a difference. It didnt. The upload and other services are all running. A lot of the devices are checking in and their status is being updated in MSP but it appears that some files in the discovery folder are being ignored and the files accumulate and status does not get updated.

I am thinking of a potential fourth cause. Imagine a given device has left its "discovery" XML report on RS, but for whatsoever reason (any of first 3) MSP does not retrieve it. So it is not deleted. Then, after a while the same device posts a newer XML on RS, with a different name. This time MSP is able to read and delete it. But the older is simply ignored, because MSP has an updated info about this very device. So it will remain forever. Does this make sense, Larry?

on the device side, the client maintains one version of the discovery document.  if it is time for the msp client to write a new discover document, it checks to see if another discover document exists for itself (dir listing using its uuid), if so, deletes the old one and then creates the new one.  the only way i can see for the relayServer to have multiple discover documents for the same device is if one of those steps is failing for any reason.  typically its because of permissions of the client-side (private) ftp login credentials.  if the device cannot delete the old discover document it will still write the new one. what kind of ftp server are you using? on the server side, the msp upload service will login using the server-side ftp login credentials, go to the discover document, get a file listing and process each file one by one.  the last step processed for each file no matter what is to delete the file if it can.  have you checked the eventlog on the msp server?  are there any errors?  again, typically its because of permissions of the server-side (public) ftp login credentials. lastly, you might want to check the directory specified in both the private and public.  after either the device or server performs the ftp login, it will change directory to the specified corresponding directory.

documents will accumulate in the DISCOVERY and possibly the CONTROL folders of a Relay Server ... 1) if the Relay Server is deactivated while managed devices are still using it - check to see if the RS has been deactivated, and reactivate it if necessary. 2) if the MSP server cannot log in to the Relay Server to "pick up" the documents for a period of time, as could result from a network problem or a change in login credentials or permissions on the Relay Sever itself - Relay Server Status should show information on the latest error recieved on this Relay Server. If the Relay Server in question does not show up on the Relay Server status list, see number 1). 3)  if for some reason "DELETE" permission is not granted to the userid that MSP uses to communicate with the Relay Server. To test for credential and/or permissions problems, you can open a command window on the MSP server (be sure to do this from the MSP server so you will get the same FTP "experience" that MSP gets) and FTP to the server using the same server ID (dns name or IP address), user id and password that MSP uses. Also use the same security mode (open or TLS) and if MSP is using Passive mode be sure to set PASSIVE. Then CD to the "Path" folder MSP uses, list files, CD into DISCOVERY and list files, GET a file, and DELETE a file. If MSP is getting FTP errors, so should you. And once you get an error, it should be clear how to fix it. BTW - There is a mechanism built into the MSP client to limit the growth of the numbers of these documents, but it can still amount to a lot of files if there is a large number of clients using the same relay server. How many devices are using the FTP servers you mentioned?