Emerson Exchange 365

Steve -
Saw identical symptoms on a site a few weeks past. Turned out to be a Windows networking issue (DNS). First, verify that you can ping from the Exec to the TS by hostname. NSLOOKUP may also shed some light. In our case, one client had the wrong NIC binding order. Another would not resolve in any circumstances, so we added a HOSTS file. That got the last node up and talking.

Hope this helps.

In reply to Ray Emerson:

Nice one Ray. I will check in the morning and let you know what we find. I think you are on the right track with DNS.

In reply to Steve Linehan:

Results of testing this morning.
1. Ping Test Successful from all TSERVs.
2. NSLOOKUP can find BATEXEC in all cases and reports IP (All Match).
3. Verified NIC Binding Order On All TSERVs.
4. Verified physical NIC's on correct networks.
5. Verified DNS addresses on our DC. All are updating and OK
6. Added Hosts file to BATEXEC and TSERV1 and TSERV2. Updated LMHosts.sam as well with all nodes.
7. Switched Batch Exec function to a new node BATHIST and downloaded everywhere.

Problem still not solved, I may be looking at a rebuild here.

In reply to Steve Linehan:

I had a similar problem once and found that it was that the DeltaV services acount password was different between the Batch exec and the station that saw it as stopped. Run Servpwd.exe on the machine to ensure that it is using the same password.

In reply to chessley:

Good suggestion, I will try tomorrow. I also removed TSERV1 from the domain and then joined it back in after purging records. Thought there may have been some stale DNS or other records in Active Directory. We are not activly using all Terminal Servers and I have offloaded users from this TSERV to other Sessions. Gives me more time to debug and try out various things before opting for the nuclear option (DeltaV reinstall or even rebuild).