Bug Report Error

[Harry Catharell]

Several times - for various reasons - there have been communication errors received from the server during a sync process

The error dialogues always have the 'Report Bug' button available and when you click on that report bug button it tries to open the MirrorSync Server Bug Report mechanism so you can send the report

However this process errors on the basis that it cannot open the page [this happens on all platforms - desktop and iPad - see screenshot attached]

The reason is that the IP address being used to open that page is the internal network IP address which cannot be reached by a remote device

So the bug reporting option tries to open: 192.168.12.23/MirrorSync/bugreport.jsp...............................

It should be opening: mobilehost.hostdomain.com - which is the DNS of the server [that is not the real domain name server but it is the one reachable from outside the network !]

If I alter the URL to use the DNS then it opens up the bug report page

I believe that we had a similar problem to this with the download link which was being produced for the spoke file also embedding the local internal IP address and you guys issued a build to cope with that and which is installed at the client now [ I think that this was v2.40513]

Any guidance gratefully received

Cheers

Harry

Edited June 29, 2015 by Harry Catharell

[Jesse Barnum]

Thanks for letting me know about this Harry.

I've fixed the problem in my development version, so that it will use either the internal or external address after auto-detecting which one it should use for the sync.

If you want me to send you this build right away, let me know, otherwise you can get it in the next public release.

This change is in the FileMaker script, so it will require re-pasting the MirrorSync script steps and distributing new offline files.

[Harry Catharell]

Hi Jesse

I would prefer the build for your development version now, please, as the client is on point of release now that testing is finished

Just let me know what to do and where to go

Cheers

Harry

Edited June 30, 2015 by Harry Catharell

[Jesse Barnum]

Here's the development build (2.40608) that has that fix for the 'report a bug' button.

Don't forget to run through the config and re-copy your MirrorSync script steps before distributing the offline files.

http://s3-external-1.amazonaws.com/com.prosc.support.uploads/Outbound/360Works MirrorSync-2.40608.zip?AWSAccessKeyId=AKIAIDQUCQL7APZLJCDA&Expires=1438262647&Signature=xxEuKfQlJ4F9Bd1TAJq4PudKBzo%3D

[Harry Catharell]

Much obliged, Jesse

I will keep you updated with how this goes

Cheers

Harry

[Harry Catharell]

One question - If we upgrade the server to new build and there are still users out there with an earlier version of the spoke file - Will they still be able to sync ?

Cheers

Harry

[Jesse Barnum]

Yes, MirrorSync server updates are always backwards compatible with older client scripts going back to the major version number. In other words, MirrorSync 2.40608 will work with any client script from MirrorSync 2.0 and later.

[Harry Catharell]

Thanks Jesse - I just know that there will be users out there who have just not got round to downloading their update even though instructed to by the client administrator :-)

Harry

[Lewis Stairs]

Hi Jesse,

I am working with Harry on this and I have now installed this new build on our clients server. When re-configuring to get the new scripts, I receive the attached errors. 

It seems to be that because we use a host name rather than an external IP address, the MirrorSync application 'thinks' that we are using the incorrect IP. 

We have never received this error before, so it seems to be something in this new build that has caused this issue. 

I have tried a sync from the spoke file and received no errors, but I haven't dare go any further than the second error message in case editing the configuration or changing the scripts 'breaks' the process. 

If this is just a warning message, I am more than happy to continue as long as the sync works, but if not shall we just revert back to the previous build?

Thank you very much for all your help so far. 

Lewis

-----------------------------------------------------------------------------------------------------------------------------

Hi Jesse,

Further to this, I found out that the external IP address MirrorSync is picking up is incorrect as here we use a gateway and the IP address of the server is different. So, the host name resolves to the correct IP address (and works in past builds of MirrorSync), but when testing against the external IP, MirrorSync collects the wrong one. 

So, in light of this information, I decided to carry on through the configuration safe in the knowing the external IP supplier is correct. Unfortunately, when I tried to copy the new MirrorSync script for the hub database I met an error that I could not continue past or 'ignore'. 

Any help would be greatly appreciated. Thank you.

Lewis

Edited July 1, 2015 by Lewis Stairs
New information needed to be added

[Jesse Barnum]

The problem is not because of using a DNS name, it's because the DNS name in question (tagmobile.appointmentgroup.com) resolves to IP address '217.207.148.222', but the external IP address used to access the internet from that machine is '217.207.148.194'. However, I tried accessing that machine myself using the DNS name and it worked, so maybe the 194 address is a proxy server or something.

At any rate, it's safe to ignore this warning, since the DNS name is working fine for external queries. I added this feature in that new development build because a lot of tech support requests we get are from people who have their external address incorrectly configured, so now we just validate that it's reachable.

[Lewis Stairs]

Hi Jesse,

Thank you for the reply - you are correct, we are using a gateway here. 

I have now gone on to continue with the configuration process, and I can continue fine until I get to copying the MirrorSync script steps. At that point, I get the same error again but I have no way of getting past it and ignoring it (see screen shot).

Do you know of anyway we could get around this, even if just temporarily? Or perhaps we should revert back to our previous build?

Thanks again for your help - and apologies for all the questions! 

Lewis

[Jesse Barnum]

You're right, I didn't realize that you couldn't get past that last step. Here's a new build (2.40612) that doesn't give as many warnings about that, and should allow you to ignore the warning on the last step.

http://s3-external-1.amazonaws.com/com.prosc.support.uploads/Outbound/360Works MirrorSync-2.40612.zip?AWSAccessKeyId=AKIAIDQUCQL7APZLJCDA&Expires=1438431484&Signature=jrrZPBNhKQBEybbewKsQtba6kRU%3D