My customer wants to simply have their existing production repository duplicated as a test environment. What are the pitfalls or considerations to do something like this? I'm thinking that there may be more to it than just copying the repository folder, volume folders, and sql database and mounting them as a new repository? I'm thinking if I do that on the same server that the repository will be trying to point to the same volume location as the current repository. what other conflicts am I going to have to sort out? What about duplicating workflows?
Question
Question
How to best duplicate a production repository for use as a test environment?
Answer
You will need to make* a copy the SQL db. Once you've copied the db, you need to run the UUidupdater tool (https://support.laserfiche.com/KB/1012907). The steps are as follows:
- Unregister from the LF admin console
- Detach from SQL
- Copy the db
- Attach the copy to another instance
- Run the UUIDupdater on the copy
- You can attach the original back to SQL and register it again.
- Once you have run the UUIDupdater on the copy, you can treat the copy like another SQL db for another LF repository.
- You will need to make a copy of the volumes at this point and make sure each repository is pointing to its own set.
For workflow, you can export the workflows as WFI files from the original and create a new WF db and import the files into it.
Replies
I'm at point 8, but I can't make a full copy of the volumes because they're huge. Both production and test repositories are currently pointing at the same volumes on a network share. How can I point the test repository away from the production volume without copying it? I expect the images to be broken, that's fine.
Thanks!
You cannot have them point to the same volumes. To have two distinct and separate repositories, you must have separate copies of the volumes. Once you have copied them elsewhere, you can change the path to the volumes in the admin console.
You cannot have them point to the same volumes. To have two distinct and separate repositories, you must have separate copies of the volumes. Once you have copied them elsewhere, you can change the path to the volumes in the admin console.
How do I change the path to the volumes in the admin console before attaching a repository that will then point to the same volume paths as production?
You have to attach it first then change the paths. Since you have another server using the files, you should turn off the other server first before you copy the files and register the repository.
Thanks Raymond, LF Team. This just solved a big problem for us.
How long does the Utility usually take to run? We are running it on a 3GB database and it has been stuck on "activity_log - columns: asn" for a good 15 minutes.
You are likely running into the issue described here:
https://answers.laserfiche.com/questions/68638/RepositoryUUIDUpdaterexe-crashing
Looks like it worked, it just got stuck on that step for some reason.
Hi Raymond,
Could you please just clarify what to do in my case. As per this guide we created the copy of the repository from the production environment and successfully attached it to dev. However path in the original repository points to the network share and when I tried to change path for the new dev server message comes up saying that files will be moved to the new location. Is it possible to suppress this? Would be copying root file structure enough to prevent moving files to production?
Thank you very much,
The behavior you are getting suggests that not all the steps above were followed.
Hi Raymond,
The repository is huge and customer does not need all files in the dev environment, so we did not copy any of them. That's why I asked for expert help searching best way (last to questions).
Thank you,
What step did you not follow?
What message are you getting exactly? and
Where or what application are you using when it comes up?
We have taken the repository from PROD environment and restored to TEST environment, also ran UUIDupdater.exe on the db. Everything seems to be working fine, but when trying to "Add" (not Attach) the repository to the TEST workflow server (not the PROD workflow server) through workflow configuration, the following warning popped up. Should we use "Attach" instead, or there is something we missed?
The link to the uuidupdater tool is no longer working. Any suggestions?
thanks
Jeff
I'm having the same issue when trying to access the KB article
We asked our VAR, and they sent the utility to us.
I see several have reported the link to the utility does not work and no response from LF. Any updated link to downloading the utility?
EDIT:
For others looking for this utility, I found it at ftp://ftp.laserfiche.com/pub/LF/KB/1012907/
The article was taken down because the utility is not compatible with Laserfiche 10. We'll put it back up with an warning.
So what are we to do for a LF10 DB?
The KB indicates the utility is still only compatible up to v9. Any ETA on update for v10?
Hi Miruna,
I'd just like to add "me too" for LF10 compatible version of uuidupdater.
I'm working on a project with multiple pre-prod and prod environments and am planning a migration process. Is there an ETA for a v10 updater?
-Ben
Is there any update on the RepositoryUUIDUpdater for version 10?
I need to copy a 10.4 repository from a dev server to a production server.
Peter, the UUID only needs to be changed if it is going to be copied to the same LFS. Making a copy on another server will work fine without changing the UUID.
If you must have a copy on the same LFS, open a support case.
Thanks Bert,
So the UUID on the repositories must be local to the server. I can have the same UUID as long as the repositories are on different Laserfiche servers.
In my scenario the two LFS are both using the same SQL server. So the repository databases are on the same SQL server, but they are created from separate LFS.
Is this an issue?
Can the two repository databases exist on the same SQL server with the same UUID?
Hi there,
When building a new environment out using an upgrade Eval licence I would like to understand better the applicable steps from above.
I just wondered what the risk is if in this scenario the existing Production Repository is not unregistered and DB not detached in SQL on the existing PROD server prior to copying both and running the UUID tool on a properly restored backup of the DB before mounting on a new Production LF server? I was hoping to not disturb the existing PROD server as much as possible. Would this be safe to do also if the existing PROD server LF service is stopped and the same PROD Volume folder gets attached to the new PROD server once the UUID has been executed on it's restored DB for good measure? We also are trying to avoid duplicating a huge 1.25 TB volume when going live but want to understand the risks involved.
Thanks,
Sorry I should have mentioned this is a legacy 9.0.2 system going to 10.4.2 on United licensing. Thanks,