Hi All, I have two machines that I export offsite as standby VM's and they both have suddenly stopped exporting. None of the permissions have changed and the firewalls are down. I did just do a round of windows updates the day before but I was still exporting right up until this afternoon. I realize that this may not be a RR issue per-se but any ideas would be appreciated. I am unable to even connect far enough to add a new machine to export. I can remote desktop the machine and ping it. Exception chain: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Cannot obtain access to a remote machine 'offsite server' This error could be caused by one of the following The user name or password is incorrect. The specified user does not have administrator privileges on the remote machine. The specified user does not have access to the remote machine via Windows Management Instrumentation. Cannot connect to the Hyper-V server 'offsite server' using the specified credentials. Please make sure the user name and password are correct

Hi Corrigun: The message "access is denied" raises a connectivity question mark which needs to be addressed first before going into more depth. Since replication goes on port 8006, the simplest test is: 1. stop the core service on the source core 2. run a telnet client pointing to the target core on port 8006 If you get a blank CMD console that cannot be closed via CTRL-C, it means that you have connectivity. 3. stop the target core service and run telnet again from the target. If you have connectivity it means that someone has hijacked your port 8006 (possibly a recently deployed Apache TomCat server) 4. Telnet again from the Target to the Source (both core services stopped) Same as above if you have connectivity it means that someone has hijacked your port 8006 5. Start the Source core service (so you have a listener on port 8006) and repeat the test the other way around. If you have connectivity (and you did not at #4) it means that the connectivity is not your culprit and more troubleshooting is needed. If you determine that there is something listening on port 8006 on either side and you cannot shut down that application, you can change the replication port as shown below. Please note that the replication port is recorded on the source core only (so there is nothing to do on the target). Hope that this helps.

Hi Corrigun, Have you double checked the user account that was used when setting up virtual standby to ensure it is not locked or the password has not been changed? Those would cause access denied. The other thing to check on is the WMI troubleshooting in this article - msdn.microsoft.com/.../aa394603(v=vs.85).aspx . It lists that error code specifically with steps for how to resolve. It's very possible that Windows Update changed some WMI permissions and now your user doesn't have remote access to make the connections/changes that it needs for export. -Tim

It appears that a bad switch was the cause of my timeout and permission issues. I am still seeing odd behavior in transfers but I have started a new thread. I will flag this as solved.

This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Virtual Standby Exports Suddenly Fail

Corrigun over 6 years ago

Hi All,

I have two machines that I export offsite as standby VM's and they both have suddenly stopped exporting. None of the permissions have changed and the firewalls are down. I did just do a round of windows updates the day before but I was still exporting right up until this afternoon. I realize that this may not be a RR issue per-se but any ideas would be appreciated. I am unable to even connect far enough to add a new machine to export. I can remote desktop the machine and ping it.

Exception chain:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Cannot obtain access to a remote machine 'offsite server' This error could be caused by one of the following
- The user name or password is incorrect.
- The specified user does not have administrator privileges on the remote machine.
- The specified user does not have access to the remote machine via Windows Management Instrumentation.
- Cannot connect to the Hyper-V server 'offsite server' using the specified credentials. Please make sure the user name and password are correct

Parents

0 Tudor.Popescu over 6 years ago

Hi Corrigun:

The message "access is denied" raises a connectivity question mark which needs to be addressed first before going into more depth. Since replication goes on port 8006, the simplest test is:

1. stop the core service on the source core

2. run a telnet client pointing to the target core on port 8006

If you get a blank CMD console that cannot be closed via CTRL-C, it means that you have connectivity.

3. stop the target core service and run telnet again from the target.

If you have connectivity it means that someone has hijacked your port 8006 (possibly a recently deployed Apache TomCat server)

4. Telnet again from the Target to the Source (both core services stopped)

Same as above if you have connectivity it means that someone has hijacked your port 8006

5. Start the Source core service (so you have a listener on port 8006) and repeat the test the other way around.

If you have connectivity (and you did not at #4) it means that the connectivity is not your culprit and more troubleshooting is needed.

If you determine that there is something listening on port 8006 on either side and you cannot shut down that application, you can change the replication port as shown below. Please note that the replication port is recorded on the source core only (so there is nothing to do on the target).

Hope that this helps.
Cancel
Up 0 Down

Cancel

Reply

0 Tudor.Popescu over 6 years ago

Hi Corrigun:

The message "access is denied" raises a connectivity question mark which needs to be addressed first before going into more depth. Since replication goes on port 8006, the simplest test is:

1. stop the core service on the source core

2. run a telnet client pointing to the target core on port 8006

If you get a blank CMD console that cannot be closed via CTRL-C, it means that you have connectivity.

3. stop the target core service and run telnet again from the target.

If you have connectivity it means that someone has hijacked your port 8006 (possibly a recently deployed Apache TomCat server)

4. Telnet again from the Target to the Source (both core services stopped)

Same as above if you have connectivity it means that someone has hijacked your port 8006

5. Start the Source core service (so you have a listener on port 8006) and repeat the test the other way around.

If you have connectivity (and you did not at #4) it means that the connectivity is not your culprit and more troubleshooting is needed.

If you determine that there is something listening on port 8006 on either side and you cannot shut down that application, you can change the replication port as shown below. Please note that the replication port is recorded on the source core only (so there is nothing to do on the target).

Hope that this helps.
Cancel
Up 0 Down

Cancel

Children

No Data