| In this small article we give you highlights on how to | | | | These scripts should capture logins on the old server |
| move Microsoft Great Plains server to new more | | | | and save them to the file. Then on the new server |
| powerful hardware with minimal problems. Here we do | | | | you create the logins from the file and then grant |
| not provide you information on GP version update, just | | | | access (via special scripts, not generically) for the |
| how to redeploy. Our approach will be to give you | | | | users to the GP companies/databaseso Server Side |
| architecture understanding, so you could make your | | | | Software. Sometimes you have such annoying things |
| decision knowing the options and technical reasons. | | | | as software installed onthe old server, utilized by users |
| You should be familiar with such concepts as | | | | in their daily operations: eConnect is good example. |
| Microsoft SQL Server and its versions: 7.0, 2000, 2005, | | | | eConnect might be used by Microsoft Great Plains |
| ODBC connection specifics, GP customization and its | | | | modified logic, GP customization or such add-ons as |
| architecture (if you have one), GP ReportWriter and | | | | Microsoft Great Plains Business Portal - check if you |
| Reports.DIC, Dynamics.set file (where you see all your | | | | use Requisition Management, Order Management, |
| GP products integrated into your GP installation), | | | | Employee Self Service and BP HR modules, Electronic |
| eConnect and Business Portal (if you deploy BP), | | | | Document Delivery - to name a few modules of BP |
| Crystal Reports and MS SQL Server Reporting | | | | family. If this is the case - you should be comfortable |
| Services (or SRS - again if you deploy CR or SRS)o | | | | to face Business Portal redeployment, with possible BP |
| Risk minimization. Begin with philosophy, not with | | | | customizations, integrations, custom logo, etc.o FRx. |
| technical side of it, especially if you in the reasonable | | | | This is financial reporting software, typically in use by |
| beginning of your career as DB Administrator, IT | | | | your top financial people: controllers, VP finance, etc., |
| specialist, GP programmer or consultant. If you move | | | | so treat it with respect. FRx has sysdata folder, where |
| and redeploy GP over the weekend and then on | | | | all FRx settings should be stored. However, this is not |
| Monday users will not be able to use it and in this case | | | | the end of the concerns - FRx publishes its reports |
| business will stop its operations - then you will be | | | | either to FRx viewer or to the files (like into Excel |
| forced to roll back to the old server and this will be a | | | | worksheets), and in the case of printing to the file - |
| lesson for you - strategy and planning is requiredo | | | | output directory might be hardcoded - unpleasant |
| Windows Server Name and IP address. Please, make | | | | result might be FRx bombing outo Report Writer |
| you homework first and get awareness if you do or | | | | custom reports. Chances are high that your GP users |
| don't have customizations: Microsoft Dexterity custom | | | | workstations deploy centralized reports - review your |
| modules, SQL stored procedures (integrations, | | | | user-side dynamics.set and find where you have |
| extensions to dex modifications, etc.), custom reporting | | | | REPORTS.DIC placed. If you have them on mapped |
| - all these are candidates that original software | | | | drive or through UNC path - you have to build up the |
| developers hardcoded server names, IP address or | | | | same shared folders on the new servero Switching to |
| placed these as parameters into setting files. If you are | | | | new Windows domain. If you are changing such nice |
| not really supporting and not in contact with original | | | | things as active directory and windows domain, then |
| programmers or reports designers - the safest | | | | think about user profiles, where user mapped drives |
| approach would be keep the same server name and | | | | might be initialized, plus printers (printers might be |
| IP address for the new server box (yes, this is what | | | | superseded in GP and when you switch to new |
| you just read - rename the old server and mount the | | | | domain with new printers management - you may |
| new Goliath hardware box on its place with the same | | | | need printer setting re-haul, not a big problem - if you |
| name and IP)o GP DB migration. There are special | | | | do not deploy such business critical printers as |
| scripts for transferring user logins and passwords on | | | | barcode labels printing, dot-matrix invoices. Etc.) |
| GP customer source. This step is required and you | | | | Even if you think that it is too complex, you have the |
| have to follow the instructions (or you might be the | | | | option to invite professional GP consultant to help you |
| one who is MS SQL Server DTS maestro - then you | | | | and plus we believe that GP redeployment is a way |
| may feel comfortable to transfer security this way - in | | | | easier that something like mainframe or Oracle |
| this article we assume you are normal IP person). | | | | Financial redeployment on the new UNIX server. |