PROBLEM:

Taking a snapshot when running the command on the target system with DataKeeper fails with error 1265.

C:\Program Files (x86)\SIOS\DataKeeper>emcmd (target-server-name) TAKESNAPSHOT (volume-letter of mirrored volume)

Status = 1265

emcmd (target system name) takesnapshot E

Running net helpmsg 1265 from a command line: Error 1265 means that the server cannot reach the Domain Controller.

The location of the snapshot is on one volume (example: Volume D:). The location of the snapshot is setup BEFORE running the takesnapshot command by setting the location in the DK GUI or by running the emcmd setsnapshot command.

The location of the snapshot can be verified by running emcmd . getsnapshotlocation E

The location of the snapshot is on one volume (example: Volume D:).

The mirrored volume is on another volume (example: Volume E:).

DEBUG/SOLUTION:

Use the emcmd command with getserviceinfo and -proxy to debug this issue (where error 1265 is seen when running emcmd takesnapshot).

From the source system (where the mirror that you are trying to create the snapshot on is the source of the mirror) run the following:

emcmd (NetBIOS/Hostname of the target system where the snapshot is going to reside) getserviceinfo -proxy .

EXAMPLE:

Target system’s NetBIOS/Hostname = node2

Source system’s NetBIOS/Hostname = node1

From a command prompt on node1 run the following commands:

cd %extmirrbase%

emcmd node2 getserviceinfo -proxy .

This also fails with error code 1265 (which means that the server cannot reach the Domain Controller).

This means that name resolution is not working correctly on the target system (where you want to have the snapshot).

To further debug this, try using the local system account to start the DataKeeper service on ALL of the systems in the cluster.

Takesnapshot works in this situation (when the local system account is used to start the DK service).

In this case, the domain that the user accounts are in that was used to start the DataKeeper service is a DIFFERENT domain than the domain that the servers themselves are in.

This can be seen in two different dksupport files:

  • sys_name – in this file find the entry for Logon domain and make sure it is the same domain that is used in the dk_state file for the SERVICE_START_NAME

  • dk_state – in this file find the entry for SERVICE_START_NAME and make sure they are not only the same on all 3 systems, but they are in the same domain that is shown in the LOGON DOMAIN in the sys_name file.

EXAMPLE:

Domain the DK servers reside in = Domain1

Domain used for the DK Service account = Domain2

Customer was using a DK Service account from a domain “different “ from the servers (Domain2) to run datakeeper services.

The error 1265 indicated unable to communicate to the domain controller, so Domain2 was not able to resolve on the DK systems (which are in Domain1).

Summary: There are 2 solutions to this issue:

  • Start the DK service on all systems in the cluster with the Local System account.

OR

  • Ensure that the domain account being used to start the DK Service is in the SAME domain that the systems are in. Start the DK Service on each system with an account that is in the same domain that the systems are in.

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment