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.
Yesterday’s “Cost” update
Here was my usage “chart” as of today:
Focusing on the “compute hours” section, the first thing that jumped out at me was the 23.87 compute hours under US East. My first thought was “no way”… then I looked up how this is calculated. First, the “incremental” hours from yesterday’s graphic are:
- Compute Hours – SQL Server = 6.27 hours
- Compute Hours – US East = 13.14 hours
I am assuming based on the numbers above that SQL Server is charged differently than the VM because that 6.27 hours seems to be about 1:1 with the actual hours I used yesterday, more or less.
As far as I can tell from reading a few other blogs, the compute hours on the VM’s are: # of VM’s x VM size x Clock Hours.
- 1 VM x 2 core machine (size) x 6.5 hours ballpark = 13 hours
- Actual charge 13.14 hours appears to be in-line with that estimate
The VM size parameter appears to be # of cores, but I could be oversimplifying that one. One isn’t exactly double the other so I’m curious how or when the clock starts on SQL vs the VM. In theory the VM starts first, then the SQL services start after the VM is running so the hours on SQL will always be slightly less than the VM hours? One day I might set the SQL services to not start automatically to see if that theory is accurate or not.
So far the performance appears to be adequate for my uses. Twice yesterday I couldn’t connect to the VM after a reboot, so I had to restart it a second time. I could have been just impatient, it’s hard to tell. When it’s a local Hyper-V, you know the status of a machine’s state a little better than you do via Azure from my current experience.
Speed wise, Steve Endow asked me to compare some speeds with him on GP launch time, as he is also playing with Azure at the moment.
The first measurement I took was a little flawed: I started GP & my timer right after I logged into the VM, but even the Server Manager hadn’t launched yet and it started right after I clicked on GP to start timing. It took 3:05 for GP to launch, login, and for the menus to be visible. Brutal obviously, but flawed since it wasn’t a “clean” start, services in the background may still have been loading. After that, I was launching & logging in to full menus in 15-16 seconds – pretty quick in my opinion!
To re-verify the first number, I rebooted the VM and this time waiting for Server Manager to appear, then closed it, then launched GP. This time it took 1:05 to launch GP, login and have full menus. Still not great. After the first launch it was back to 15-16 seconds to full launch.
Otherwise, I haven’t been doing any measuring of performance to give concrete feedback…
Beware of the “Temporary” Storage (D) drive!
When my VM first launched, I noticed there were 2 hard drives:
The one labelled “Temporary Storage” had a text file in it, a “read me” type of file. It basically said “never ever store anything here you aren’t prepared to lose”.
They weren’t kidding!
Next time I launched the VM after a reboot, that warning was gone. It is indeed temporary. It is primarily used for the page file. I’m unclear if it’s specifically cleared after a reboot, or only on shutdown/restart but in any event, don’t save anything on it if you aren’t willing to lose it without notice.
Here is a file I put in my D drive yesterday:
And later yesterday after some reboots, here’s the D drive again:
Sure enough, the file’s gone. So, the best use for this drive is any processes where you need to save a file, do some kind of processing and then pass it on somewhere else. That’s not exactly the kind of thing you do with ERP work, although I can think of some integrations where you might need to store a temp file or temporary report output scenarios where you really want to delete them when you’re done.
Printing from Azure
I meant to include this in yesterday’s post but forgot. I *totally* expected printing to be a pain in the butt. I mean, you often get printing issues from even simple on-premise remote desktop or Citrix/Terminal Server scenarios.
I was very pleasantly surprised when this worked with the simple install of the proper printer driver for my multi-function laser printer/copier/scanner.
Unlike RDP’ing to a local network resource, I didn’t just automatically see my local resources whether they be local drives or local devices like printers. That didn’t surprise me, I know I haven’t connected the Azure Virtual Network to my local network.
I googled it and the tip I found was:
- Install the proper printer driver for your machine.
- The recommendation is using a local printer (i.e. USB connection) not a networked printer. Mine happens to be local at the moment due purely to some on-going renovations at my house… in a few weeks my printer will be networked again, and I’ll update the post if this changes things.
- Use the “TS00x” port which is a terminal server port of your local computer.
To install my printer, here’s what I did (no screen shots as this seemed fairly standard to me):
- Go to Control Panel and Add Printer
- I clicked on “the printer I want isn’t listed” to bypass the search
- I chose Add a Local Printer or Network Printer with Manual Settings option
- On the Choose a Printer Port page, I used an existing port and on the drop down list you should see one or more “TS00x” ports. I saw 4 (TS001 through TS004) with no distinguishing features between them. On my local laptop I have 4 printers although only one of them is “real”. The other 3 are default ones installed by Windows I’ve never removed. Anyway, I “guessed” and chose TS001. Guess what? It. Just. Worked. Go figure. That NEVER happens to me! I printed a test page and immediately my printer started spitting out the test page – no delay or lag. Impressive!
I’m quite sure it won’t be this easy for all of you or all printers. My printer (Brother DCP-7065DN) is a multi-function laser, copier, scanner and it happens to have a Windows Server 2012 printer driver which is what I downloaded and installed. I’m sure not all printers have up to date drivers for Windows Server class operating systems so YMMV.
I won’t go into specific detail on the process but this went smoothly. The only issue I ran into wasn’t anything to do with Azure. I had Fabrikam installed and when I restored the databases, I skipped it, but forgot to remove the company from the Dynamics Company Master table. Sure enough, the upgrade failed on the Company Master table. The message was vague, something about a temporary table not getting deleted. However, because it was specifically the Company Master table, it reminded me that there would be a record for Fabrikam in there still, and once I removed it, the upgrade succeeded.
The only other odd thing was after installing the registration keys, not all of the menu options were available to the ‘sa’ user. Financial transactions were gone for instance. In past years, I don’t recall having to close and re-open GP to make the menus re-appear but I did this time. No big deal, just one of those minor irritants.
First thing I did after upgrading? Run some comparison reports to verify the upgrade… and guess what? I could *print* them! Small things amuse small minds I guess…
More to follow as my journey continues. Next steps are to expand on what I’ve installed. I’d like to install Management Reporter but that will require adding a domain, so I may not tackle that one immediately!