Method Community

I am having trouble getting the Method Integration Engine to sync from a freshly installed Windows Server 2008 R2 machine.

I am using the same QB data file (Enterprise v 11.0) and the status console of the Engine reports that the Company file is open, but I cannot get the Engine to report any further status.  It tends to show "waiting for secure https connection" at the bottom of the screen, but I cannot get it to do anything else.

The server is showing good connectivity to the internet and I was able to update QB, although the web connector is reporting an error related to writing to the log file, QBWC1085.

The error related to the web connector log file reports that the web connector will still be launched, just without the log, but I have not confirmed that the web connector is still running.

I'm assuming the successful company file message indicates success of the engine connecting to QB, but the engine is having a problem connecting to Method?

I have also reset the Quickbooks file, and Computer to Synch with settings on the Quickbooks tab of Method since the hostname of the server will be different, although the ipaddress and company filename should be the same.

I've tried enabling the trace function in the Engine, but I can't see anything and the logfile location indicated from Help > About isn't a valid Server 2008 R2 path.

Any ideas?  Any security settings I need to free up on 2008 R2?  I've disabled the IE enhanced for the Administrators account which is the one under which I run the QB session and Engine.

James

Now checking Windows Firewall.  I think this may be the cause.  Typically a message gets thrown when Windows Firewall is the problem but I suspect the Server 2008 R2 (R2 is a BIG change to 2008), may have some rules that apps aren't expecting to see.

No such luck turning off Windows Firewall.  The Engine reports that the Company File is Open, briefly flashes the starting synch message, and says "waiting for secure https connection".

Do I need to configure IPSEC settings on the server to allow the connection to made to the Method Server?

The Engine will sync from a PC running QB accessing the QB file on the 2008 R2 Server.  But the Engine on the server stays hung waiting for https connection.

jnoneiliv1:

Any ideas?  Any security settings I need to free up on 2008 R2?

Is there any antivirus installed and can you confirm the firewall is disabled?  If the answer is no to those then I can have a look via GoTo Meeting to make sure everything is installed correctly.  Please email me your company account name at c.ridgway@methodintegration.com to setup a time.

~C

jnoneiliv1:

But the Engine on the server stays hung waiting for https connection.

This could be Windows server being locked down so just make sure you're installing as the admin user.  I also dug up this post which will allow you to configure the Method Integration Engine to use a specific port range.  You'll need to open those ports but this might help with the engine being stuck on waiting for a connection.

~C

Thanks Chad.

Our MSP, Wyn Consulting, fixed the problem.  I'm not sure exactly what was wrong, but there was some issue with the QB instance on the Server, which could have contributed.

The problem may have had nothing to do with the Server, but I did notice that the "temp log path" from the About panel of the Engine is incorrect.  I had tried to use the Trace function to isolate the problem but it is not functional.  The program data and application data paths have changed a good bit from XP, 2003 to Win7, 2008 R2.   These might be correct in the code of the engine, and the About panel is just wrongly hard coded to report the wrong path.  Maybe the trace file is working, and I just needed to dig around the directory, but the About panel should be corrected and probably it should use a variable to report the path based on the version of windows that the Engine detects.

Other than the logfile, I don't think we found anything specific about 2008 R2 that's going to be helpful to anyone else.

I made sure all installations, etc. were done from a user who was in the Local Administrators group, if not the superuser account, and I opened up ALL the security.  So, unfortunately I can provide no firewall configuration experience, etc.

I think as we get into Server 2008 R2, etc. it's probably  best to have an experienced Sysadmin to the installs anyway as the additional layers of security in each successive release of Win Server create new potential for problems due to server config that an application installer may not be able to address.

Cheers,

James