CA Service Management

Hi Team,

Many thanks for the assistance and support I received from the community.

Issue description: In the production server we had installed the CA service desk.For example:In the server we have three disk drives like C,D,E.CA service desk is installed in 'E' drive space allocated is 200 GB,now the total drive is got full.i had checked the folder which had used more space.Below are details

Folder location: E:\Program Files (x86)\CA\Service Desk Manager\site\attachments\default\servicedesk\files

Folder name: rep_folder_00001

So its creating new folder day by day and size is increasing.

So I need to increase the drive size or need to clean/delete some files.

Kindly advise.

Thanks,

 Sohail

Hi Sohail.

The solution lies within your environment team whether you need to increase the drive size or need to clean/delete some files. Either way this should help you resolve the issue.

If you don't have resources to add then you have to fall back on cleaning/back up the old data to free some space for the application to work fine.

You can fall on to archive purge solutions to delete the existing data using the available documentation on Archive/Purge

SDM 14.1

https://docops.ca.com/ca-service-management/14-1/en/administering/configure-ca-service-desk-manager/managing-your-database/how-to-archive-and-purge-historical-data

SDM 17.1

https://docops.ca.com/ca-service-management/17-1/en/administering/configure-ca-service-desk-manager/managing-your-database/how-to-archive-and-purge-historical-data/

Let me know if this helps?

Hi Sohail,

• That folder 'rep_folder_00001' probably belongs to the default attachment repository.  Can you obtain some space on a network file share to move the default attachment repository off the SDM host?  That would give you some breathing space to monitor the growth and do some investigation.  If you need help on the details of how to do that please get back to us.
• As Maheshwar recommends, configuring archive/purge is always a good practice, and over time that should reduce the growth of the attachment repository.
• Looking at the files in the repository folders, you should be able to see from their creation dates whether they are accumulating in line with the natural accumulation of tickets, or whether there has been some recent increase in the number and/or size of attachments being created, and from there get some indication of how much storage you are likely to need going forward.

Hope that helps,

Regards,

James

Hello Sohail,

How did you go with this?

To pull out the key points:

* Move your file repositories somewhere else for now.

This is good practice anyway. A busy file system has its own requirements which are different to that of an application server.

* Examine the files to make sure that the attachments are actually valid.

I saw one site where a vast array of "unexpected" attachments (automatically generated reports from a reporting server misdirected to the SDM maileater account) was blowing out the attachment count.

Or it may be the case that users should be trained to link to knowledge documents rather than attach them to the ticket.

Thanks, Kyle_R.

Great advice from Kyle and James. We’ve moved all our attachment storage to a nas share and limit attachment size to 10MB. I’d suggest setting a size limit per attachment if you havent already.

Can you guide me regarding the size limit per attachment

Here: Setting the maximum file size of Attachments in Se - CA Knowledge 

Hi Kyle,

Followed the above  link and there are many repositories with 0 KB

Thanks,

 Sohail

Hello Sohail,

Do you mean many files within a repository of size 0 bytes each?

Then that's a problem. (Useful Attachment) files should not be of 0 bytes in size. 

See: 

Zero-byte file - Wikipedia 

What is a zero-byte file? 

You need to investigate this. It could indicate that the Attachment upload is starting, but failing to complete.

• Potentially the "full drive" you mentioned was allowing the creation of the file name, but stopping after that.
• See if you can work out where the files are coming from. What and who is producing them? What size should they be? Can Wireshark help?
• Make sure that the drive is not corrupt (run chkdsk or equivalent.).
• Run Anti-virus check, and check it is not blocking anything. Same with the firewall rules.
• Make sure that a valid Attachment of positive byte size works. Is the 0 byte file issue reproducible? How often?
• Backup your database and Attachments as a precaution. (Although the 0 byte files won't be useful to keep)

Check out everything that you can about these files and the file storage environment. You need to be sure the file system is stable in the first instance. 

Then check out Service Desk. You may need to log a Support issue to put additional logging on.

But this helps answer part of your original question - I would be deleting all of the 0 byte files, as they serve no use.

Thanks, Kyle.

Many Thanks for the information  Kyle,

Path:E:\Program Files (x86)\CA\Service Desk Manager\site\attachments\default\servicedesk\files

In the above path mentioned there is folder by name: "files and within the folder there are rep_folder folders ",which many notepads with 0 KB, previously the notepad was occupying some space.