GoToMeeting vs. Mikogo for desktop sharing and web conferencing

I've used GoToMeeting for years to provide remote support to Dynamics GP customers and do some remote presentations to small groups.  It has worked very well overall and has done a great job of meeting my needs.  While more expensive than Microsoft's offering, I can confidently say that GoToMeeting is vastly superior to Live Meeting, and I also like it much better than WebEx.

Although it is a great service, I do occasionally have some problems using GoToMeeting.  This morning I had a GoToMeeting session scheduled with a new client.  We both dialed into the GTM conference number and were on the call, but when the client clicked on the GoToMeeting link that I had provided, he said nothing happened.  Customers sometimes do have some issue clicking on the meeting link--whether it is a browser issue, or a problem downloading or installing the GoToMeeting client app.

So I asked my client to open a web browser to navigate directly to www.gotomeeting.com.  When he tried that, he said nothing happened.  The web browser would just 'spin' and he couldn't connect to the web site.  He even tried entering the IP address in the browser address bar, but he still couldn't connect.  Obviously this isn't GoToMeeting's fault.  There was apparently something with the customer's network, firewall, or proxy that was preventing any connection to the GoToMeeting web site.  Since things like this happen, it doesn't hurt to have a backup.

Quite a while ago, a colleague told me about a free GoToMeeting alternative called Mikogo, and he spoke very highly of it.  I gave it a brief try and saw that it seemed to work fine, but since I normally used GoToMeeting, I didn't have much need for it.  Well, this morning I was scrambling for an alternative to GoToMeeting so that I could help my client.

After several Google searches to remember the name, I found Mikogo and downloaded the latest version.  In just a few minutes, I had signed up for the free account, had a meeting started, and a few seconds later, the client was connected to the meeting and showing his desktop.  Mikogo worked great and really saved the day.


Now that I've used it once and taken a few minutes to check out some of its features, I thought I would provide a review and compare it to GoToMeeting.

The full Mikogo client application is about 9.5 MB, so it may take a little while to download, but it installs very quickly and easily.  Attendees who join your meeting can download and install the "Connection Program", which is about 5 MB and runs on the remote machine without requiring an installation.  Mikogo also has a Join a Session web page that lets an attendee select an HTML Viewer option, allowing them skip any downloads and join the session right in their browser window (view only).  I tested this on my iPhone and it worked great--I was able to see my desktop session on my phone and the refresh rate and speed seemed very good.

When Mikogo launches, a small, simple control panel is displayed.

Interestingly, Mikogo allows you to create and save different session "profiles" that let you to specify options like whether or not to display your task bar or whether you want to allow participants to see file transfer options or record the session.  For simple customer support sessions, it may be preferred to turn off many of the options to keep things simple and easy for you and the user.  I found this option interesting and appealing.

Like GoToMeeting, Mikogo uses a 9 digit "Session ID", so it is simple to share with meeting attendees.  And like GoToMeeting, Mikogo allows you to create a new session at any time, or have multiple scheduled sessions.  Mikogo also has both a Chat and Whiteboard feature, very similar to GoToMeeting. 

Similar to GoToMeeting, Mikogo allows you to choose which applications are visible when you are presenting.  But unlike GoToMeeting, which only lets you select one application at a time, Mikogo lets you selectively enable or disable the display of multiple applications.  This is a great feature.

So if I want to show Word, Excel, and Dynamics GP, but want to hide Outlook, Live Messenger, my desktop wallpaper, and even my desktop icons, I can do so by clicking individual checkboxes.  And unlike GoToMeeting, the presenter can display his Mikogo control panel to the attendees, and vice versa.  This is very helpful when you need to show a user which button to click to perform an action on the control panel--something that I regularly struggle with when I ask clients to click on the "Give Keyboard and Mouse" control option in GoToMeeting.  This multiple application display feature is very clever and very nicely implemented.  Mikogo also supports multiple monitors, like GoToMeeting.

One significant feature that Mikogo offers that is not available with GoToMeeting is File Transfer.   The lack of file transfer is one weakness with GoToMeeting.  Although I don't need to use it very often, I've had plenty of situations where it would have been very convenient to transfer a file as part of the remote session, rather than having to use e-mail or FTP.  This is a big plus if you are doing a lot of interactive work and need to transfer a data file, SQL script, documents, etc.

Mikogo offers a unique "URL Push" feature, that lets you send a URL to attendees, which can automatically open that URL in their web browser if they accept the link.  This can be done via chat in GoToMeeting, but the URL Push makes the process simpler for the user.

Like GoToMeeting, text copy and paste works between the presenter and attendee sessions, so you can copy and paste text in both directions.

Mikogo provides screen scaling and resizing, so displaying smaller or larger screen resolutions isn't a problem.  It also has a handy zoom / magnify feature in cases where the presenter has a much higher screen resolution.  The screen scaling was relatively good, although it didn't seem quite as sharp or as readable as GoToMeeting when a high resolution presentation is scaled down to display on a lower resolution display.  But it is still very good compared to other services I've tried, and Mikogo even provides a Session Profile option to increase or decrease the picture quality, presumably for performance.

In terms of drawbacks of Mikogo compared to GoToMeeting, so far I've only found two small ones.

First, it appears that the screen refresh 'speed' with Mikogo is slower than GoToMeeting.  GoToMeeting seems to be better at quickly updating the cursor location, and it seems to be faster updating the overall display.  The Mikogo speed is perfectly acceptable, but since I'm used to GoToMeeting, I immediately noticed the slightly slower speed.  I was testing with two machines on my wireless network, but obviously Internet connection speeds will vary by session and participants with any web conferencing solution, so real world performance may vary.

Second, a minor difference is that the Mikogo client doesn't display conference calling options by default.  They do offer international telephone audio conferencing options, similar to GoToMeeting, which you can configure to be displayed in the Mikogo client, but those don't automatically appear like they do in each GoToMeeting.  More importantly, Mikogo does not appear to yet (see update below) have a Voice Over IP audio conferencing option like GoToMeeting, so if you do a lot of international sessions, that may be a drawback.  All of my non-US customers used the VoIP option in GoToMeeting, so I would have to use Skype or some other VoIP option if I were to use Mikogo for those sessions.

UPDATE:  Mikogo has informed me that they will be adding a native VoIP voice conferencing feature, with beta testing starting very soon.


With all of that said, I think Mikogo is a very impressive, very capable web conferencing and desktop sharing solution that can compete fairly well with GoToMeeting.  I would personally choose it over Microsoft Live Meeting any day without question.

So now let's talk about pricing.  Mikogo used to be an exclusively free offering.  But they have recently transitioned to a "freemium" model.  This means that they offer their product for free for personal use, but kindly ask that you buy a subscription if you are using it for business or commercial use.

They have several "single user" subscription options, depending on how many participants you need in your sessions.  At this time, their "Basic" plan is $13 per month, which allows up to 3 simultaneous participants per session.  The "Pro" plan is $19 per month, and allows up to 15 participants.

$13 per month seems like a great price considering how much functionality Mikogo provides.

They also offer "multi-user" plans for organizations that want to share a pool of subscriptions, although you'll have to do the math on whether this is any cheaper for your organization.

As a comparison, GoToMeeting is currently $49 per user per month, or $468 for a year.  That's $312 more per year than a Basic Mikogo subscription.

If you are on a budget, that's quite a difference.  It's enough that when my GoToMeeting renewal comes up, I'm going to have to seriously consider whether I should switch.

I've only used Mikogo "for real" once, so I would have to use it a lot more to see if there were any other quirks or drawbacks, but if you are shopping for a web conferencing or desktop sharing solution, I would definitely recommend checking out Mikogo.


Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com

Developer Gripe: "An unknown error has occurred"

While at the Dynamics GP Technical Airlift two weeks ago, I was speaking with someone who mentioned that Management Reporter was driving them nuts with a generic error message:

An unknown error has occurred

That's it.  No further description, no error number, and no further clues as to the cause of the problem, when or how it occurred, or how it might be resolved.

In short, an utterly useless error message.

Coincidentally, Christina just wrote a blog post about one possible cause for this generic Management Reporter error.  Who knows how many other reasons may cause that error to occur.

This generic error message is coming from Management Reporter.  A relatively new, modern Microsoft product.  Not that Microsoft products are known for their illuminating error messages, but they don't get much worse that "An unknown error has occurred".

I'm no Super Hero Developer, but I have never written a program that had such a lame error message.  It's puzzling for a few reasons.

First, the fact that the message is displayed in a dialog box means that the error was detected or trapped by the application.  This means that some part of the application code anticipated that there could be some type of "error", is handling the error, and is displaying the error message.  I understand that not every possible error can be anticipated, but when an error is being thrown, and you have an error handler setup to display a dialog box, it is negligent to not provide any information to the user as part of the error message.  What would be the point?  Displaying highly technical or a very specific detailed message is better than nothing--at least the user can send more info to an administrator or consultant who can then evaluate it rather than spending hours aimlessly trying to guess the problem.  Or it can at least be sent on to Microsoft as part of a support case to help their internal debugging. 

Second, more generally, such a useless error message seems to indicate an application architecture or development methodology that is designed to not provide error information to the user.  That's not an accidental choice.  It's something that has to be intentionally, designed, coded, reviewed, tested, and released.  As I said, I'm not a Super Coder, but even I develop my relatively simple applications to capture and expose error messages.  It makes the customer's life easier, and it makes my life easier.  Why a development team for a commercial Microsoft software product would implement such a generic error message design is baffling to me.  If my applications can do it, certainly Microsoft could pull it off.

Last, I would argue that there is no such thing as an "unknown error".  There are only "expected errors" and "unexpected errors".  If you display an error dialog box, then by definition your application has detected the error, and the error is known.  Something caused that dialog to display based on some condition in your code.  You may not know the scenario or specific cause or details, but you fundamentally know that an error occurred.  However, that error may be expected or unexpected.  Expected errors are those that you anticipated and handle explicitly.  Unexpected errors are ones that you didn't anticipate, and handle generally (such as with an Unhandled Exception error).  An invalid GL account or an invalid date might be expected errors--you anticipated that a user may enter an incorrect value.  A divide by zero error might be unexpected--until you see it happen, identify the cause, and add validation to check for a zero denominator--and then it becomes an expected error:  "Hey, you can't divide by zero in that formula!".  In either case, you can capture the error and display a meaningful message with actual information that a human might find valuable.

What makes it puzzling is that good error handling and error messages aren't particularly difficult to do with typical business applications.  They aren't typically dealing with low-level functions like CPU instructions, hardware drivers, or low level network connectivity, so there aren't too many excuses for not having decent error handling.  It just takes a little bit of knowledge, some basic design practices, consistent coding, and project management.  I'm confident the team that developed Management Reporter could easily improve the error messages if it were made a priority and a practice.

Users, customers, consultants and developers:  Demand better error messages.

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com

Dimension Filters in Columns in MR 2012

I came across an interesting issue in Management Reporter 2012 last week with a client.  They had recently upgraded and found that one report did not work.  They would generate it, and receive "An unknown error has occurred while processing report".  So we did some basic troubleshooting, and were able to isolate the issue to the column layout.

While testing with the column layout, we noticed that the error only occurred when we included columns that had a dimension filter that was adding and subtracting dimension sets.  And in contacting Microsoft, we found that it was a recently reported quality report.  The actual issue is with regards to subtracting, it doesn't matter if it is dimensions or dimension sets.  If you use a (-) in a dimension filter in a column layout in MR 2012, you may encounter the error.  There are a couple of workarounds...

1.  Create a dimension set that includes the necessary dimensions and any subtraction you need to include
2.  Create two hidden columns, one with the dimensions you need to add and one with the dimensions you need to subtract. Then use a calculated column to perform the necessary math.

Word from Microsoft is that hopefully this will be fixed in the October update for MR, we will keep our fingers crossed.  Although this may not seem major, it is one of those annoying "quirks" that I am always happy to see fixed :)

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

Back in the saddle

You may (or may not) have noticed that the past couple of months have been filled with Steve's awesome technically profound blog posts while little has been heard from myself in that time.  Well, I actually have a really great excuse....

Carter Wesley Phillips joined our family on July 23rd at 11:23am.  So I have been out on maternity leave, and I actually did not work for most of it!  And, yes, for those Johnny Cash fans out there...that is a "Crawl the Line" onesie that Carter is sporting in the picture above (which was taken when he was 3 days old).

I am excited to be back in the saddle, and promise some real blog posts soon.  I was so disappointed to miss the Technical Airlift in Fargo, so I have really enjoyed catching up on the fun reading all of the blog posts from the event :)

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

How do I find the eConnect 2010 version?

During lunch today at the Dynamics GP Technical Airlift conference in glorious Fargo, I was asked "How do I find the eConnect 2010 version?".

The question was asked because the eConnect 2010 service packs have no dialogs, no status indicators, and no indication that they have completed or installed successfully.  So after installing the service pack, you don't really know if it ran, and you can't tell whether eConnect was updated.  You are left wondering, "Did eConnect really get updated?".  You feel compelled to check something to confirm the eConnect version.

With eConnect 2010, the definition of the eConnect version changed slightly.  With GP 10 and earlier, eConnect version numbers were values like 10.0.3 or 10.0.5--these were values stored in the database that related to the version of the eConnect SQL objects.  But with GP 2010, the eConnect version numbers are now values like 11.0.1761.0 or 11.0.1923.0, which are not related to the SQL objects.

The eConnect 2010 version number format is different because Microsoft is now referring to the version number of the eConnect 2010 run-time files.

To check the eConnect 2010 version, open Windows Explorer and navigate to:

C:\Program Files\Microsoft Dynamics\eConnect 11.0\API

Right click on the eConnect.dll file and select Properties.  Then click on the Details tab.

Once you have the file version number, you can open the Dynamics GP 2010 version list Excel file, go to the eConnect tab, and determine which eConnect service pack is installed.

The follow up question was:  "But then what is the point of the eConnect Release Information application under Start -> All programs -> Dynamics -> eConnet -> Release Info?".

My understanding is that the eConnect Release Information application is now of little or no value.  That application queries the GP databases to determine the version of the SQL eConnect objects--but those objects are now updated by the GP service packs, not by eConnect service packs, so that version number will no longer correspond to the eConnect service pack installed on any given machine.


Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com

Dynamics GP 2013 Beta Available for Download on PartnerSource

As announced this morning at the Dynamics GP Technical Airlift conference in Fargo, the Microsoft Dynamics GP 2013 BETA is now available for download on PartnerSource. 

https://mbs.microsoft.com/partnersource/support/selfsupport/productreleases/MDGP2013_TAPReleaseDownload.htm

It is sitting queued in my File Transfer Manager at the moment without starting the download yet, so it looks like there might be a lot of people all trying to download it today.

Lots of Beta code caveats, so read the release notes and test on a disposable test server.

Good luck!

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com

Interesting eConnect PA Misc Log Bug: Fiscal period for posting date does not exist

Today I finished up developing an GP 10 PA Misc Log import using eConnect.  I was doing some final testing in Fabrikam and everything was looking good in the Misc Log transactions.

I then clicked on the Distributions button (because one should ALWAYS test the distributions on any transaction import), and after I clicked OK to close the distribution window, the following error message was displayed:

The following errors were found while validating distributions:

Fiscal period for posting date does not exist


Hmmm.  Okay.

I went to another transaction to check the distributions but the error did not appear.  I tried to check other distributions, but I couldn't seem to reproduce the issue.

I deleted my test batch and reimported it again.  I pulled up the first transaction in the batch and was able to reproduce the error.  So I open the distribution window to see what might be wrong, and I confirm that there is no posting date visible on that window.  I check the eConnect documentation and confirm that there is no posting date field that can be set--and regardless, the distributions are being defaulted by GP, so I'm puzzled why the distributions would have a problem.

I then check the database tables, starting with the Misc Log Distributions Work table, PA10203.  There is no posting date in that table, just basic distribution info.  Then I check the Misc Log Work table, PA10200.  While browsing the dates, I see something odd.  One of the transactions has a value of "1900-01-01" in the "PAPD" field.  The rest of the transactions have the proper test date of 7/1/2017.

I reviewed the eConnect documentation yet again and confirm that there is no posting date available--only a document date. 

After doing more testing, I determine that only the first transaction that is imported has a bad posting date.  Very odd.  At first I think it's because it's the first transaction imported for some reason, but after doing more testing that doesn't seem to be the case.

After a few more rounds of tests, I finally figure it out.

By default, the Fabrikam company is set to use a Batch posting date for Misc Log transactions (Setup -> Posting -> Posting -> Post Date From:  Batch).

So that "PAPD" field value is technically coming from the batch posting date rather than from the transaction data that I am sending in to eConnect.  But for this import, I am not creating the batch--I'm just sending in the Misc Log transactions and letting eConnect create the batch automatically.

Well, it seems that there is a bug in the Misc Log import.  When the first Misc Log transaction is sent to eConnect for a new batch that does not yet exist, eConnect is not properly setting or updating the PAPD date value for the transaction.  Perhaps it is inserting the transaction first (resulting in a PAPD value of 1/1/1900) and then creating the batch, but not updating the PAPD value.  Or perhaps when it inserts the transaction, it attempts to get the batch posting date, and returns 1/1/1900 because the batch doesn't yet exist.

In any case, it's a small but annoying bug, since it will potentially affect the transaction posting.

There are two potential workarounds.

1. If the client has their posting setup to use Posting Date From:  Transaction, the bug is not triggered, so the import should work fine.

2. If the client uses the posting date from the Batch, then you can create the batch first, using the eConnect taCreateUpdateBatchHeaderRcd transaction type, and then import the Misc Log transactions.  As long as the batch exists with a valid posting date, the transactions should import with the correct PAPD value.


Again, this is on GP 10 / eConnect 10 SP3.  I don't have time to see if this was resolved with a GP 10 service pack, and I haven't yet tested with GP 2010 to see if it also exists there.  In the unlikely event that I can test it with GP 2010 (or when the client upgrades), I'll try and post an update.


Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com