MattHamilton

FWIW I have linked this issue to IE's default use of compatibility view for intranet sites. This can be disabled manually under compatibility view settings, or via group policy. As far as I can tell the web interface is now working perfectly using IE11

Hi, Today I upgraded a client's installation from 5.1.0 to 5.2.3 - this is the highest version I had which their license would support - I'll talk to them about maintenance when they're back from holiday. I was hoping that the web interface in the new version would work better when using internet explorer as we had some strange behaviour before. Unfortunately it is now much worse as per the attached image and I can't log into the web interface using internet explorer at all now The interface is fine when using Chrome and users who need web access access have been using Chrome anyway as this was required previously but surely this should work? The client's standard browser is IE11 on Windows 7 Pro 64.

Yes but the 32 bit version doesn't work on Windows 2008 (32bit or 64bit) either so I'm not sure what enhanced backward compatibility you are referring to. Windows Server 2008 is a currently supported platform with extended support from Microsoft until 2020, I am certainly not going to recommend that my clients upgrade their servers because you don't know how to or can't be bothered compiling and testing software to support this version. FWIW even Visual studio 2015 offers client compatibility back to XP/Server 2003 http://www.visualstudio.com/en-us/products/visual-studio-2015-compatibility-vs.aspx I have also provided information suggesting how to resolve the specific error encountered when starting the service on Server 2008 Most concerning is the lack of information and informed support. Nowhere does your website or any specific forum responses mention which version of windows are supported or that some are not compatible, You have even asked other customers with similar issues to test for themselves which is what I have had to do and have proven your assumptions wrong.

Quoting my previous post "I managed to find a 5.1.3 32 bit installation package which installed fine, but as with the 64 bit version the service doesn't start after upgrading." The installation failure aside the 32 bit upgrade failed in the same way as the 64 bit, resulting in a non starting service. Let me know if you have any plans to do testing of your software prior to releasing new versions or in response to reported issues on any platforms other than recent version desktop operating systems. As it stands this is a completely unacceptable level of support for a commercial application and I will being researching alternative solutions for my clients.

Thanks for the reply but unfortunately the 32 bit version won't install either. I have provisioned a 32 bit Windows 2008 server and have exactly the same result with the 32 bit installation package. I managed to find a 5.1.3 32 bit installation package which installed fine, but as with the 64 bit version the service doesn't start after upgrading. Screenshots of the error and system details are attached. I don't understand why you keep referencing desktop operating systems, Windows XP and Windows 7. Who in their right mind is running a production system on non-server platforms, do you do any testing of new builds on different platforms as there seem to be a lot of assumptions being made? Is your software no longer fit for commercial use?

Here's some more info I have uncovered on the Kernel32 reference which is causing the service startup failure. The MSDN page for GetProcessMemoryInfo (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683219%28v=vs.85%29.aspx) suggests that this due to a difference in linkage between Windows 7 and earlier versions; Windows 7 directly defines GetProcessMemoryInfo as K32GetProcessMemoryInfo in Kernel32.dll, whereas earlier versions call GetProcessMemoryInfo in Psapi.dll which wraps to K32GetProcessMemoryInfo. Possible solution: "Programs that must run on earlier versions of Windows as well as Windows 7 and later versions should always call this function as GetProcessMemoryInfo. To ensure correct resolution of symbols, add Psapi.lib to the TARGETLIBS macro and compile the program with -DPSAPI_VERSION=1. To use run-time dynamic linking, load Psapi.dll." Could the developers please consider that although they are likely to be compiling and testing on Windows 7 or newer systems any currently supported Microsoft server platform should be expected to be still used in production. Windows Server 2008 has extended support from Microsoft until January 2020, even Windows Server 2003 R2 still has extended support to July 2015.

I have done further testing on this and have confirmed that the installation fails on a new test Server 2008 64 installation but is successful on server 2008 R2 There is no mention of this compatibility issue in the release notes and all I have found in the forum is a very uninformative post, possible from a dev, mentioning that the app is now compiled in VS2014 and may not work under XP which I'd be surprised if anyone would be using to run a production server, Server 2003 is the equivalent server OS version Worse still an in place upgrade using the XML link is performed without detecting this issue and results in a non-starting service. Could someone please confirm why as of 5.2 the Vodia pbx is not compatible with Server 2008 and presumably Vista and older Windows operating systems as well.

My client is currently running 5.1.3 (Win64) and I am attempting to upgrade to 5.2.4 I have attempted this every way I can think of with no success. If I perform an XML based upgrade the service will not start after the upgrade. If I perform a manual debug startup I receive the error "the procedure entry point k32getprocessmemoryinfo is not found in kernel32" In researching this I found some mention of installing C++ runtime, Visual C++ 2008 runtimes are already installed. Another response was to uninstall and re-install the software. When I attempt to do this the installation nears the end and then fails reporting an error with the installer. Researching this I have found posts that Windows XP is not supported, the server I am installing on is Server 2008 64. Do I need to upgrade to an even newer version of Windows server to install the latest version?

I have been having a lot of issues since upgrading to Snom One 5.1.3 over the Christmas period. The current issue is that call history is not working in either the web interface or UC Client, Call History, Missed Calls and even active calls in the admin interface are all empty. I did attempt to upgrade the latest version last week but had to revert as the service refused to start with the new version installed.

Sorry, I can't see a file to download. Could you please let me know where to download it from?

I have an issue at a a client since upgrading to Snom ONE 5 where the LED status of the Agent Login/Logout Button is not updating. Some phones are working OK while some are stuck with the light on and others are off. Previously the login/logout star codes were different but as per the current manual I have set them both to *64 and the login/logout toggle works but does not update the LED status. Restarting the PBX seems to resolve this temporarily, restarting the phone has no effect as it restarts with the same LED status as it was previously so this does seem to be a PBX issue with regard to the recorded status of the phone. All of the agents are using SNOM 320 phones on the latest firmware - 8.7.325. The PBX is currently running SNOM One 5.1.3