subject: Dynamics GP Test Environment Installation, Loading with Data Sets [print this page] Dynamics GP Test Environment Installation, Loading with Data Sets
If you are implementing Microsoft Dynamics with moderate or heavy customization planned, test server and environment are recommended. Custom programming requires testing scripts and software quality assurance activities. Technically it is possible to consider some QA against the data, available in Lesson Company. However, the software programming nature needs alpha, beta and final product release to be tried against the copy of the production company. Let's review the steps to install the staging data set. This paper might look a bit technical and Great Plains terminology oriented. We recommend also have MS SQL DBA or consultant to be available. If you do not have SQL administration expertise, consider contracting this job to your GP VAR (they have certification requirement to carry SQL Administrator in staff). After this small introduction, let's move on to details:
1. Installing Client Application on the test server (with SQL Server side scripts). You can work directly on the Server (dedicated to be test one), or assign one Windows 7 (Vista or XP) workstation, where client interface could be loaded. If you already have production environment (assuming that modification project is considered to be rolled out in the phase two, when standard version of this Corporate ERP is already implemented in the first phase), be sure that you applied the same service pack, as in production. Apply Service pack prior to launching Utilities
2. Companies placeholders creation. Here need to be sure, that you understand GL Account Segmentation (maximum length and number of segments). Launch Utilities and create companies with exactly the same DB Names (company database name)
3. Loading placeholder companies from production companies backup. Here you need help from your MS DBA. This is typically done in MS SQL Server Management Studio. You also need to load Dynamics (or ERP system) database from production backup
4. User Security transfer. If you search knowledge base on the Customer Source (or Partner Source), there is article on how to move user logins and passwords from production environment (with SQL 2008 and 2005 there are complications with advanced password and user ID options, password transfer is only guaranteed is you name test environment server exactly the same as its production counterpart; this is why we recommend you to transfer all the user ID and simply reset passwords for each user via GP interface)
5. Management Reporter or FRx. Dynamics ERP Management Reporter is client server application, meaning that reports are generated and stored on the SQL Server DB level. Old-good-days FRx generates reports, based on its metadata (Microsoft Access file FRxRpts.f32 default specification set)
6. Modifier with VBA files transfer from production environment. There are files with .DIC extension in Dynamics.set file for each modified dictionary. Plus, if you are deploying VBA scripts, look for the .VBA extension files in the GP user workstation directory (typically C:Program FilesMicrosoft DynamicsGP), such as Dynamics.VBA. These files should be copied into your test workstation folder
7. Dexterity Customizations and ISV Add-ons. ISV solutions need to be also loaded on the test user interface. If your custom programming is planned to be performed in Microsoft Dexterity, copy its export (so-called chink file)
8. Report Writer Reports.DIC. You need to be sure that your test box has the same pointing to the modified reporting dictionary (check Dynamics.set file in the production environment and if required copy Reports.DIC and other modified Add-ons associated dictionaries)
9. Crystal, Excel, MS Access and other reports transfer. Please, note that this procedure deviates from standard Great Plains installation practice (as CR or other popular tools are generic ones and you have flexibility and associated responsibility to install them according to your experience)
10. Integration Manager. If you need to have this tool tested, please open it in production workstation, then in menu: Tools -> Options, record Default Integration Manager Database location. Then, copy the file, recorded above to the staging environment and install IM with the switch to its database accordingly
11. Customization Upgrade Projects. Here you need to have source code for the earlier version. If it was done in Great Plains Dexterity, please be sure that you got Dynamics.DIC (or Extract.DIC) file from your original Dexterity programmer. If you do not have these files, this might be a big problem, as when Dexterity chunk is integrated, the created dictionary doesn't have source Sanscript codes (they are stripped out)
12. Older Version versus Recent versions of Great Plains user workstation installation. With the introduction of Microsoft Installer (where you can add GP new modules and components directly from your computer Control Panel Add or Remove Software), some flexibility was lost. For example, in older version (where Windows Installer was not used) you could simply install GP from old version CD (or the same version as in production but without applying Service Packs). Modern Windows Installer keeps the track on the installed applications (and service packs), and copying over (from production Program Files to test Program Files) is not an option
13. Notes on FRx compatibility or incompatibility with Windows 7 and Windows Server 64 bit platform. FRx is in phasing out, beginning with version 10.0 and 2010/11.0. New development (in the form of FRx Service packs) is not planned for GP (latest frozen version is 6.7 with Service pack 11). Microsoft Management Reporter is supporting 64 bit platform by its technology. There seems to be reliable migration toll from FRx to MMR. If you are large organization, we recommend you to try test migration (MMR is only one plus few months old product, as we are writing these lines in April 2011)
14. OLE Notes. In order to deploy OLE Container Notes, please open your Dex.ini file on the user workstation, and change its location to the server UNC (we assume here that in your production environment you are deploying OLE notes on the server via UNC Path or mapped driver)
