LBI Deployment from DEV to TEST to PROD

We are in the process of setting up this scenario now. We have a production LBI server/DSSO/LBI resides within the main portal window. We are adding a LBI server/DSSO/Ect in our CERT environment. Our Cert environment and PROD are mirror images of each other unless in the last round of testing CERT has a few patches not yet in PROD. It is also our upgrade/MSP/ESP testing environment.

We decided to remove the DEV/CERT connections from the PROD server. In building CERT we are only buiding the CERT/DEV connections. We will have Super Users building content, reports, dashboards in this CERT LBI enviroment. That content will be reviewed by my team in IT, validated for speed, indexing,etc.

Once we have ok'd the report, users are finished testing and the roll out plan has been developed; we will put in an IT Change Control Ticket for each change, new report, etc. Most of these will be low level changes, but we want to track them for the annual IT audit. If the report/change, is high impact we will present it at our weekly change control meeting. We don't anticipate many going through that meeting.

Any reports built in PROD today will be replicated by changing the data source and being published to CERT. We are using this as an opportunity to clean up, outdated reports and not rebuild these in CERT. We use very few back office reports but I would say any we have will follow the same process.

Since we are in process, I can follow up in a couple months and let you know how it is working.

Hey Mark,
Im trying to do the opposite. I want to copy my LBI PROD to LBI DEV.
However I would assume that the process would be similar. Any ideas?

And how did it go for you? Please give us an update.

Thanks,

UPDATE:
I opened up and incident with Infor Support regarding this and the bottom line is this. LBI customers can "refresh" (or copy) LBI DEV to PROD by using Solution Packs, however, these are limited: It can copy dashboards and reports, however it will not be able to copy, schedules, rights, devices, device types, structures and elements. For my purposes it is practically useless. This is the ONLY supported process.

The support person did mention another way which is to restore a copy of PROD db to DEV. However, they do not recommend nor support that (I know right!).

Maybe people here can contribute/help with this predicament.

its true its not supported (using database backups to migrate content) but i can say that Ive done it often. It really is the only way to migrate vast amounts of content. Of course you need to make sure youre on exactly the same version of FS, RS and SN (or whatever apps you are migrating). Then youll need to copy the entire LawsonDocuments directory if migrating RS. After that youll need to go into the InstallValidator for all the apps and update URLs and references. There are other places through out the apps youll find that you need to update but for the most part Ive found it to be rather seemless.

As Lawson says, its not supported so try at your own risk.

Well said, Matthew!! If I could, I'd offer some of the most troubling sources of URL's embeded in the DB are located on the Tools dashboard. For which I've found the little-known and previously undocumented http://lbiserver.domain.c...0/efs/BrowseServices invaluable in fixing.

So I have client who inadvertently restored FS, RS, and SN from PROD to TEST. No backup of TEST exists. I have updated all the services and confirmed via the BrowseServices utilitiy. The issue I have is that FS install validator still has reference to the PROD system in two places. Under the System Settings (#10) I get a message reading "The URL for this system is set to 'https://productionlbi-server:9443/efs/', this does not match the detected address of 'https://testlbi-server:9443/efs/'

Additionally, under test #11 (EFS Page Domain Setting) I am receiving the error: Testing URL: https://productionlbi-ser...efs/fs/js/servenv.js The URL above could not be used from the EFS server to access itself "

I don't understand where these references to the productionlbi-server are coming from. They must be in the data somewhere, because that was the only thing that was changed.

Any ideas....???

Your fix for #10 is to put the correct URL in the box, and click 'Submit' from the InstallValidator itself.
This will likely fix your #11 as well.

I think the best thing I can do now, is just go ahead and take this opportunity to go through the exercise of refreshing TEST from PROD. I have been able to correct the error above and reconfigure RS so that I can get in and see all the reports, settings, etc... that would have otherwise been valid for PROD.

I have backed up the existing TEST report repository for good measure, and I'm copying the reports from PROD. If I am correct, and everything (data sources, permissions, etc...) are reconfigured correctly, I should be able to get everything back up and online much like it is in PROD, only on TEST. ;-)

At least that is the plan for now.

Be careful of your scheduled reports. Every report that was scheduled in prod, will now be scheduled from TEST and (at least here) that presented a problem... at least confusion on the end-user part as to which report came from which system.
I actually went in and disabled all of the schedules.. and to be safe, entered a bogus mail server in our TEST environment.
When users actually want to test, I have to remember that no email will go out until I change that.

I guess I will continue to use this thread as it seems the most appropriate, but I have need to migrate LBI from one server to another. My primary concern is the reports, specifically making sure historical instances are still accessible.

Has anyone been through this, or know where I need to look/update in order to make sure this goes off as smooth as possible?

FWIW, this does not involved an upgrade of LBI.

you will have to do it using the method I described above unless you want to republish every single historical instance.

Thanks. I think there could be version difference between some components, but I have not verified that just yet. Do you know what tables contain the pointer to the historical instances?

If you are bursting and scheduling the historical instances are stored in ERS_PUBLICATIONS2.

The support person did mention another way which is to restore a copy of PROD db to DEV. However, they do not recommend nor support that (I know right!).







___________________________
[url=http://www.diagnosticobd2.com]obd2 diagnostic tool [/url][url=http://www.diagnosticobd2.com/gm-tech2-gm-diagnostic-scanner_p271.html]gm tech2[/url]

[quote]
Posted By Greg Moeller on 01/03/2013 01:33 PM
Well said, Matthew!! If I could, I'd offer some of the most troubling sources of URL's embeded in the DB are located on the Tools dashboard. For which I've found the little-known and previously undocumented http://lbiserver.domain.c...0/efs/BrowseServices invaluable in fixing.
[/quote]

This link was just a lifesaver. We are currently upgrading from 9 to 10 and I could not find any reporting services stuff even though our implementer said it was all installed. I was able to verify they have installed ERS but did not migrate over any of our reports and data sources.

2 thumbs up (didn't see an emoticon for that)

any ideas if your ers validation is not working post data copy? links work everything else seems to be there?