This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Moving Archive Manager to New Server

We are currently running Archive Manager (5.3) on a Windows Server 200R2 instance, and are considering a move to a 2012R2 server.

The current server has all the services, the attachment store and the website as well as SQL server installed on it.

We have found the KB articles that explain how to move the attachment store or the SQL database to another server.

 

Our question relates to the Full Text Index.

If we install Archive Manager on a new server (having already moved the attachment store and database), point the new install to the current database and attachment stores what about the FTI?

Is it possible to move the FTI, or is a full rebuild of the index required in this scenario?

Thanks in advance ...

 

 

Parents
  • (A couple of years ago) using the advice from Dave we stopped the service updated the paths in the database and moved the folders to a different location.

    We actually moved them within the original server, to a different drive (on a faster disk)  and moved the SQL instance to another server which combined gave us the desired increase in performance.

    This all appeared to work as expected.

    However we have now noticed that all the newly created partitions that have been created since the change are in the original path F:\Quest Software\ArchiveManager\Index

    We can follow the same process for moving the existing partitions that are in the 'wrong' location, however we would obviously like to have any new partitions created in the 'correct' location.

    My question relates to how we do this.

    • The Configuration Console > Advanced Settings includes an entry Full Text Index Location however this is set to a value of F:\ArchiveManager\Index so it would seem that this setting does not control this (and perhaps this is a legacy entry?)
    • In the database table [FTRolloverPolicyID] there is a Locations column that is set to the path where the new index files appear to be created. Is updating the path in these Locations row entries the correct way to update the location for the new files to be created?
    • Or should this change be made through the (web site) Administration console > Index Rollover Policy > Partition Locations? > Add E: as a Drive, remove F: then 'Update Rollover' (for both Message and Attachment)
    • Or something entirely different?

    Thanks in advance ...

Reply
  • (A couple of years ago) using the advice from Dave we stopped the service updated the paths in the database and moved the folders to a different location.

    We actually moved them within the original server, to a different drive (on a faster disk)  and moved the SQL instance to another server which combined gave us the desired increase in performance.

    This all appeared to work as expected.

    However we have now noticed that all the newly created partitions that have been created since the change are in the original path F:\Quest Software\ArchiveManager\Index

    We can follow the same process for moving the existing partitions that are in the 'wrong' location, however we would obviously like to have any new partitions created in the 'correct' location.

    My question relates to how we do this.

    • The Configuration Console > Advanced Settings includes an entry Full Text Index Location however this is set to a value of F:\ArchiveManager\Index so it would seem that this setting does not control this (and perhaps this is a legacy entry?)
    • In the database table [FTRolloverPolicyID] there is a Locations column that is set to the path where the new index files appear to be created. Is updating the path in these Locations row entries the correct way to update the location for the new files to be created?
    • Or should this change be made through the (web site) Administration console > Index Rollover Policy > Partition Locations? > Add E: as a Drive, remove F: then 'Update Rollover' (for both Message and Attachment)
    • Or something entirely different?

    Thanks in advance ...

Children
No Data