I do not thingk so, You can make 2 file server active. BSA will be pointing to only one file server and repeator is only the option.
What is concerns in using repeators, you can sync data during non business hour or weekend?
Many thanks for your answer!
The restriction is that the software packages should not leave the new site - so they should not be stored outside that site. So with repeators they would be stored in the primary site - which should be avoided.
Do you know of any other possible solution?
You can only have a single reference to a file server, what you can do if you need to store packages other than there is to do a softlink, this will leverage the content from its current location. When the job is executed, the payload will be temporarily copied to the appserver and then deployed.
I hope this helps.
The use case you're describing here is something we call a Remote File Repository.
To leverage this, you would use the "Mount at Install Time" feature for the payload location in the software package, and use a Windows or NFS (UNIX) share at the remote site as the location of the software package. Some customers will parameterize the location of this package to be able to reuse the same package definition with many remote sites.
The net effect is that the central management infrastructure (the app server etc.) controls when and how the software gets deployed, and you get to use a simple remote file store for actual payload deployment. Please follow up with any questions: this is a powerful feature of BSA, and very helpful for large payloads (like SQL Server) or where bandwidth between sites is constrained.
(This does not directly use or replace the BSA File Server, of which there can be exactly one, and which should be closely located to the application server infrastructure.)