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 actually am re-creating this post as it appears to have disappeared! Hmm…
An update on my Azure experiences… apparently I forgot to turn off my Azure VM one day last month. I say apparently because I don’t recall using Azure to turn it on, but perhaps I did, anticipating doing something, then forgot. It happens.
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.
Recently I’ve been playing with Microsoft Azure and installing Dynamics GP 2015 on Azure, upgrading my GP 2010 test environment etc.
One of the things I needed to try to get working was FRx. I haven’t gotten to the point of adding Active Directory on Azure yet, therefore I don’t have a domain and can’t install Management Reporter. Same. Old. Problem. I hate that MR requires a domain, it really limits test and demo capabilities in my opinion… but I won’t rant on that right now!
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.