Most organizations that I have seen using Windows server typically just have the repository locally on the ALM server to maximize performance, and they just take regular backups of the repository. If they have a clustered environment then they would just use the UNC path in the dbid.xml so that the secondary node can also get to the path, so for example the path would just be'' \server1almrepository'' this way reguardless of whether the ALM server making the quest is ''server1'' or ''server2'' they can both see the repository. I have not seen anything at HPE/MicroFocus regarding CIFS and if it is supported or not.

What I think you should probably do is a test to see if this CIFS could be what is slowing it down, I would like you to try the following:

1. Create a new project in ALM

2. After the new project has been created go grab the repository from your CIFS location and copy the repository to the local hard drive on the ALM server
the default location for this is ''C:ProgramDataHPALMrepositoryqcDefault'' (this would be for the ''default'' domain)

3. The new project is still pointing to the CIFS location so you will need to go in and change it, in the site admin schema/db find the ''Projects'' table, then find the row that references the new project you just created, there should be a column called ''PHYSICAL_DIRECTORY'' change the value for that row to the local harddrive location that you moved the repository above. (ALWAYS have your DBA supervise this kind of change and make sure you have a backup of the ALM site admin DB before attempting any changes)

4. I would now delete the CIFS version of the repository for the test project

5. Now restart ALM (you need to do this so it references the new location of the repository)

6. Open site admin back up and make sure you can ''ping'' the project

7. If that all worked you should have a new test project with a local repository instead of CIFS

8. Test to see if you get the slowness issue with a local repository