If you have been around Great Plains for awhile you might remember that in versions previous to GP 10 you could run GP without having to actually install the software. This made rolling out the client to lots of workstation very quick and easy. All you had to do was;
1. create an ODBC connection to the SQL Server
2. copy the GP folder to the workstation and create a shortcut to dynamics.exe that references the appropriate dynamics.set file
All you really had to do was one installation and then follow the above steps to get the client out to your workstations. One installation can take 15 minutes. You can image the time savings of having to do only one install if you had 30 workstations that needed GP.
So, along comes GP 10.
The GP 10 client won't run out of a folder like GP 9 because it needs the Windows registry as well as some new DLL's that have to be registered on the workstation. Unfortunately, there is no way around having to install GP 10 on every workstation that needs to run Great Plains. Major bummer, I know! Don't worry, there is a silver lining to this post.
If you have come to this blog after testing a GP 10 service pack you might already know that it took 10-20 minutes to install depending on the performance of your test workstation. Now you still have to run GP Utilities to start the database upgrade which could take hours depending on how much data you have. If you are part of the team doing the service pack implementation, you have a long night ahead of you. Here are some tricks to save yourself a lot of time.
Let me state the obvious before getting into the weeds. MAKE SURE YOU HAVE GOOD BACKUPS BEFORE DOING ANYTHING!!!
Also, build yourself a test environment. This isn't as complicated as it might sound. If you only have one server install another instance of SQL then install GP 10 on a test workstation with an ODBC connection to the new instance of SQL. Now you have a test environment! Easy.
See a previous blog on doing a parallel upgrade
1. On your test workstation install GP 10. Overwrite the GP folder of the new installation with a copy of a production GP folder. This will ensure you Dexterity codes matches your production database version. Install the appropriate service pack. Keep a copy of a the production GP folder prior to running the service pack install so you can roll back if necessary. Make sure to keep a copy of the GP folder when doing the production rollout as well.
2. Restore a backup of your production GP data (DYNAMICS and company databases) to the new instance of SQL. Copy all SQL logins from the from the original SQL instance to the new instance. http://support.microsoft.com/kb/246133
3. From the test workstation launch GP utilities and start the upgrade. So far, pretty standard.
4. Now for the good stuff. Once you have your test workstation working with the new service pack and you have THOROUGHLY tested everything you can now do your production rollout which you can do in 6 easy steps.
1. Once all users are out of the production GP, backup and restore your production databases to the new instance of SQL.
2. Launch GP utilities on your test workstation and upgrade your databases again.
3. While the upgrade is running, create an ODBC connection on all of your workstations to the new instance of SQL.
4. When the upgrade is finished and successful, including modified forms and reports, launch GP from the test workstation and test.
5. If testing is successful here is how to save yourself 7.5 hours to get the service pack on all 30 of your workstations.
6. Copy the GP folder on your test workstation and overwrite the GP folder on your production workstations. Make sure your users login with the correct ODBC connection which points to the new SQL instance. Done!
You now have applied a service pack to your GP installation and all workstations. If you assume a service pack install takes 15 minutes, which is pretty optimistic, you just saved yourself about 7 hours! You have also not changed the state of your production data if an emergency roll back is necessary since you cut over to a new instance of SQL and you kept a copy of you original GP folder.
****Asumptions for this example****
1. Installation path of GP on all workstations is the same
2. All modified forms and reports are centrally located (stored on the network not locally on the users workstation)
3. OLE notes are centrally located.

1 Comments:
I wouldn't update workstations this way. There is so much things outside the GP folder that may need to be updated, like Dexteriy Common Files or VBA...
Post a Comment
<< Home