Issues running WinCC OA 3.16 on Windows Enterprise LTSB 1607 (in a VM)

[tpjctrl]

Curious if anyone else runs their WinCC OA 3.16 in the following configuration:

- host PC running Windows Enterprise 1607 64bit
- VM running on the host (tried both Hyper-V and VMWare VM running in VMWare Workstation), running Windows Enterprise 1607 64bit, with WinCC OA 3.16 Client running on it

Regardless of the VM configuration (amount of RAM assigned, amount of vCPUs etc.) we are seeing loads of freezing up on mimics which are more script heavy, even the login mimic freezes up and constant clicking around with the mouse triggers the "Program is not responding, would you like to close it or wait for it to respond" popup in Windows. Same exact hardware set up running Windows Enterprise 1607 64bit on the host and a VMWare VM with Win10 Pro + WinCC OA 3.16 runs fine without issues, so we are starting to think that Enterprise 1607 is the culprit.


Has ETM done any testing with Windows Enterprise 1607 on the host running VMs with Windows Enterprise 1607 and WinCC OA 3.16?

Regards,
Tom

[tpjctrl]

I've been checking the panels where the freezing issue happens and managed to conclude that if I comment out the factory built function initHosts() (in the installation folder, scripts/hosts.ctl), or specifically the dataHost() function inside that script, then the login panel where freezing normally occurs, loads normally.

Any ideas why dataHost() is causing problems?

Regards,
Tom

[tpjctrl]

Just in case anyone stumbles upon the same problem, this thread led me to re-check my config settings:

viewtopic.php?f=15&t=4752&p=961185&hili ... st#p961185

It turned out that both data and event where pointing at two servers A and B, but only A was defined with an IP address in the Windows hosts file. After adding B to the hosts file, all runs normally now, but what is interesting that neither the server, nor the client were logging any errors, so this was fairly hard to spot (the B server doesn't even exist so ping B returns nothing anyway which is why it was ignored in the first place). Might be worth escalating to the dev team as this is definitely something which would be handy to as as an error in the logs.

Regards,
Tom

[leoknipp]

In the prerequisites for a redundant system it is described that you need to configure the hosts file.
If a host is defined in the config file the WinCC OA manager tries to resolve the IP-address/hostname. To get this information a call of an operating system function is made. If the definition in the hosts file is missing it can take some time until the answer is received from the operating system.

Best Regards
Leopold Knipp
Senior Support Specialist

[tpjctrl]

All I'm saying Leo is that it would be nice to know that the S8 connection times out, especially since 90% of the project runs fine and it only tries to check both servers occasionally. If you have nothing configured in the hosts file, then you'll know as the project won't run, indicating a "can't connect to ##", something that is easy to spot and resolve. If only one of the redundant servers is defined in the hosts file, the project starts fine, but there's no indication that comms to the other fails due to lack of IP address definition in the hosts file.

Regards,
Tom

[kilianvp]

Always first check if the DNS resolution works with each other! That solves most issues in redundant server projects.

[tpjctrl]

In the prerequisites for a redundant system it is described that you need to configure the hosts file.
If a host is defined in the config file the WinCC OA manager tries to resolve the IP-address/hostname. To get this information a call of an operating system function is made. If the definition in the hosts file is missing it can take some time until the answer is received from the operating system.

Best Regards
Leopold Knipp
Senior Support Specialist

Just to double check is the configuration of the hosts file running on the client a must for a redundant system or can WinCC OA rely on a DNS resolution through the DNS server? we are currently experiencing issues whereby the client can't connect to any of the WinCC OA servers even though it seems to resolve their names properly to their IP addresses (I can see that it translates the name into an IP address in the log and I can ping both WinCC OA servers from cmd line using their names only). If we put the WinCC OA server names and their corresponding IP addresses in the client hosts file, everything works fine, but the assumption was that this wouldn't be necessary as the DNS server does the resolution.

Regards,
Tom