I am working on setting up a test environment. I have done this before but on separate servers. This time due to resource constraints I have to do it on The same server as production. Because this is on the same server I want to make sure I don’t run the risk of affecting live data.
I have restored the live database to a test database.
I am in admin console adding the database to the console. Should I use the same deployment server when registering the existing database?
In the application server setup I know I have to setup a new application pool connect it to the appropriate database set new admin console settings etc. Can I use the same SSRS reporting server or should I create a new one?
When this is all done I believe I have to regenerate database models so that the views etc point to the test DB.
What else do I have to do to ensure I am not going to mix environments?
I have both Prod and Test on the same Appserver and SQL Server. I do have a DEV box that is wholly separate. As for Test/Prod cohabitating, they each get their own DB, Appserver, Reportserver DB, and extension deployments inside the Admin Console. IIS will end up with two sites/app pools (and more if you do the extensions).
As for inside the UI - you need to split up the data directories. We have a share for “epicordata” and one for “epicortestdata” and inside those are where our crystal reports folders are with our custom reports. SSRS takes care of itself when you create the appserver instance with the Admin Console.
To get this to all work right, we run a script to change a bunch of values in the SysCompany table when we copy over Prod into Test.
What scripts do you have to run? I am not sure what would need to be changed in the system tables. Like I said I have done this on separate servers and never changed tables. If I remember correctly from a server that was setup like this we never had to change tables either when we copied over production to test. I do remember having to do run the regenerate database models. Right now I guess the biggest question I have is do your database servers in the admin console share the same deployment server?
I have a SQL script to disable certain BPMs in Test after every restore from Prod, but I discovered last time that this doesn’t always work. It still attempted to auto-print some labels, and failed for a different reason. Turn off anything that emails or prints automatically.
If you copy file attachments, you’ll want to change the root location.
@MikeGross You just made me realize we only have one EpicorData folder. Where did you change that?
I see the script has a comment for “-- Regenerate the Data Model” (but with no actions).
That reminded me that the Regen should be performed too. Especially if the test environment had some UD changes that never ended up being deployed into the Live Co’s DB.
Well I have the server configured and I get can’t get the app pool to stay running and connect to the application server. This is the error I get any ideas?
Not Connected.
Application Server version has not been verified. Review the Error Message below to troubleshoot your connection issue. It may indicate you need to manually install a newer version of the Administration Console to connect or that it is not supported.
Error Message:
The message could not be dispatched because the service at the endpoint address ‘net.tcp://servername/ERP10Test/Ice/BO/UserFile.svc’ is unavailable for the protocol of the address.
It just means that the EAC (Epi Admin Console) cannot connect. You’ll get this if there isn’t a user setup in E10, with the same credentials as the domain user selected to deploy the App. Try launching the client program and login in as manager, as described in the new install guide.
BTW - make sure the user used to deploy the App doesn’t have a password that expires. If it does, the App will fail to launch when that user changes their password. You’d have to go into EAC and update the password, and re-deploy.
I have found that the userfile.svc error sometimes occurs when the appserver is first built and that a reboot of the server fixes it.
I’ll also agree with @ckrusen but add that I use an AD admin level account for ALL epicor services and logins that interact across the platform - essentially everything from appservers to EDA Sync happens under a user called ‘epicorservice’. That user has a high level of access in SQL server - and it has a complicated password and is immune from my password policy in AD. Makes life simple when trying to troubleshoot some issues like you are having.
Ok. So my issues I worked on until 10pm last night and fixed were.
App pool would stop when I tried connecting was resolved by using a built in user on the app pool itself. The server may need a restart which I will do but we run two shifts and I am not ready to have production workers mad at me for Epicor going down. I will likely complete this on the weekend and try the AD user that all other app pools use. The domain user is not disabled, locked, or password expired so I am thinking a restart may help but not sure.
The second issue I had was extended UD tables were not in sync. Even running a regen data models did not work. To resolve this I moved two files from the production assemblies to the test assemblies and it worked. the files were
Erp.Data.910100.dll
Ice.Data.Model.dll
If I missed something else or anyone knows that I did wrong please feel free to help me understand and ultimately get me to the answer. Currently the environment works which was my end goal. I can’t help but feel that maybe I did something wrong but the data is editing the test db and appears to be working independently of the live environment.
Thanks for all your help. I hope to hear feeback from everyone if I could have done something different or if I still need to do something different. I also hope someone else finds this useful.
The single AD user ‘across the board’ was the best suggestion I was given years ago…
I’m not an expert on the data regen and the associated files, but I have seen cases (on here I think) where the only solution was to stop the appserver, find/delete them(the ones you specified), run the rgen again, and restart the appserver. Looks like you may have had the same kind of issue.
including the stuff Calvin is talking about.