I recently purchased a new laptop and loaded it up with 16gb of RAM so it could handle having multiple instances of Microsoft Dynamics GP on it. Two of the instances are of GP 2016. One of the wrinkles of having test machines with multiple instances of the same version of GP is ensuring you apply service packs to exactly the instance you want, without affecting the others.
Here’s another pet peeve of mine when it comes to Integration Manager: changing the default IM database on each installation. Like my previous post on how to register IM quickly, here’s another tip on using the .ini file settings to your advantage to roll out workstation installs quickly and painlessly.
I’m working on an upgrade at a client from GP 2010 to GP 2015. Part of this involves upgrading Integration Manager to the newest version. As I opened IM the first time on a new install, I am reminded of what a pain in the butt it is to manually put the reg keys in each workstation.
I started reading an old installation document to update it, a document that was written by someone else for their GP 2010 installs. It struck me that many people still don’t know there is a faster way to register Integration Manager on every machine, instead of having registration keys handy to cut and paste into each installed workstation. The instructions include the keys and the steps to put new keys in on each installation.
I lost an evening that I’ll never get back over something so stupid I wish I had just stopped to think about this issue a little more.
The situation was this: I just upgraded a client from GP 2010 to GP 2015. I didn’t upgrade the test companies, because it’s a waste of time right? So I finish the upgrade and proceed to create new test companies and take fresh backups of the new production companies and restore to the test companies.
This is officially the last post, for the foreseeable future, on my experiences with Azure. There isn’t a ton of meat in this one, as it’s more of a “what’s happened since the last post” type of post.
Pretty soon I’ll have to be more creative with the blog post titles! Part 193 …. geez.
More stuff I’m learning: it’s way easier to install and configure Active Directory Domain Services on Azure than installing SQL Server 2014 fresh on a Windows-only VM. Seriously… I’m on my 3rd attempt to install SQL Server!
If you’ve read my last post, part of the What’s Next was creating a standard VM, installing A/D on it and installing SQL Server on it. This is not and never will be anything close to a production machine, so the significant faux-pas of having SQL Server on a Domain Controller seems like an acceptable risk to me. Since I have test & development licenses, instead of paying by the minute for the license, I figured I should be able to start with a standard Windows O/S VM on Azure and go from there.
One month has been completed, and my Azure experience cost me $18.80 for a month. If you’ve been following this series so far, you’ll know by now that I haven’t left the machine running outside of when I am actually using it yet… hence the extremely low cost to date. And of course, it didn’t *actually* cost me anything because I was using my MPN credits.
Day 3 of using Microsoft Azure and things are becoming a little more clear. I haven’t *done* much with actually using apps on the VM yet, more messing around with installs and configuration. This is a continuation of my first two posts on learning Azure in the context of upgrading to GP2015 for testing. Part 1 is here and Part 2 is here.
As I sat up til nearly 1:00am last night (er, this morning) playing with the new Azure VM, I was thinking “this is going SO smoothly!”. I should have known it wasn’t going to be that easy. 🙂
See yesterday’s “Part 1” post for the introduction to this journey I’m on, which covers why I’m doing this, going from a new subscription to provisioning a SQL server VM. At the end of yesterday’s post, I stopped at “I’ve provisioned my VM”. After that I tried some things, and ran into a problem.