The current server we're using for attachments is on it's last leg and will probably crash at any moment. We copied everything to a new server yesterday and tried to cut over last night. I entered the new server name in the Attachment Settings window and changed the password, the username had the same rights and the target folder stayed the same. However, the target folder is now on E: instead of C:, but the permissions/sharing are the same. When I click on Test connection, I'm getting the FTP-error: 550 Attachments: The system cannot find the file specified.
I found the updateattachments.bat that's used after an upgrade, but I could not find any instructions on how to use this tool or if it was even necessary since we didn't upgrade the application.
We're on SP11 and just moving the attachment server. Please help! This server is fading fast and we have over 14Gig of attachments at risk (I'll work on archiving on the new server!)!!
You should trouble shoot this with the ftp command at a command prompt. The screen shot seems to say the user has no permissions to the directory. I would check the permissions the user has to the dirctory where attachment will be stored. You at least need to be able to connect with the ftp account and upload a file. If you cant do that then servicedesk will not be able to either.
I actually opened a case with HP, which is probably the only way this would have gotten resolved! When I started comparing the IIS FTP, I noticed on the old one that there was only one and that's where the home directory was incorrect, and so I created a new one on the new server and just stopped the Default. When I deleted the one I created and modified the Default FTP configuration, everything worked. Since the Default was just stopped, I guess SD was still trying to use it because it was still there.
Anyway, thanks for the input! I have the long explanation from HP, if you want me to post it.
First of all, I am glad that the problem was finally solved. After our webex session, I wanted to explain you what the cause of the problem was.
Issue was that permissions on the Default FTP site's home directory (which you had stopped) were made accordingly for the user (in the physical folder), but even though you were using a virtual directory, the default FTP path was still there, no matter if it is stopped or running.
The local accounts did have READ rights (in IIS and NTFS folder) to the FTP virtual directory, although not for the root folder (which is configured always in the default FTP site), even though the FTP root home directory has a completely different path than the virtual directories (e.g. FTP root was in C:\root\inetpub and your virtual directory was in E:\service_desk), read privileges are still needed to the root in order to access the virtual directories under it.
In this case, we deleted virtual directory and just kept working with the default FTP site, changing the default home directory from c:\root\inetpub to e:\service_desk; problem resolved.