Domain Change

I need a solution

Dear ALL

recently I have been enfected by ransome ware any haw my Domain controller have been enfected so I changed the windows but i forget to demote the symanted server from the domain and now 

i cant access the symantec endpoint protection manager and also i cant istall the endpoint with is member of the new Domain 



  • No Related Posts

Successfully Deploying XenDesktop in a Complex Active Directory Environment

The following environments assume that XenDesktop 5.x is installed on all DDCs and VDAs. This article is based on the registry based Controller Discovery – this is the recommended method for multiple forest registration.

The NetBIOS and Fully Quality Domain Name (FQDN) can be different. For example, the NetBIOS name could be BOB but the FQDN could be parent1.local or the NetBIOS name and FQDN can be the same:

Example: NetBIOS name is parent and the FQDN would be parent.local.

Note: Dots in NetBIOS names are not recommend.

Appropriate user access permissions are given for successful machine creation. In a cross-forest setup, use Delegation Control Wizard to keep permissions to minimum use. Permission must be given for the DDC Administrator to create machines in a different forest in a specific Organizational Unit (OU). The following minimum permission can be given for successful machine creation:

  1. Open Active Directory Users and Computers Microsoft Management Console (MMC).

  2. Right-click your OU and select Delegate Control.

  3. On the first screen, click Next.

  4. In the Users & Groups screen, click Add and pick a user or group you want to delegate rights to and click Next.

    The best practice is to assign a group rather than a single user, as it is easier to manage and audit.

  5. In the Tasks to Delegate screen, select Create a custom task to delegate and click Next.

  6. In the Active Directory Object Type screen, select Only the following objects in folder and select Computer objects.

    User-added image

  7. Select Create selected objects in this folder and click Next.
  8. In the Permissions screen, select General and then select Read and Write.

  9. Click Next.

    User-added image

  10. Click Finish to complete the delegation control.

Different types of Active Directory Setups

Simple Single Domain Deployment

The following diagram illustrates a XenDesktop deployment in a single Active Directory domain, where the DDCs, VDAs, and the users are all in the same domain.

User-added image

In this Single domain setup, all relevant components and objects are based on one single domain. Registration of VDAs with the DDC should be successful and no additional configuration, that is, the registry key changes is required.

Following is a list to check if VDA is unable to register with the DDC:

  1. Check Event Viewer for errors on both the DDC and the VDA.

  2. Ensure that the firewall is open for port 80 between the VDA and the DDC.

  3. Check that the FQDN of the DDC is correct in the registry setting of the VDA machine. On the VDA, check the following Reg Key:

    Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.

    HKEY_LOCAL_MACHINESOFTWARECitrixVirtualDesktopAgent and confirm the parameter ListOfDDCs had the correct FQDN.

    If using 64-bit Virtual Machine, the VDA Reg Key is HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixVirtualDesktopAgentListOfDDCs

  4. Ensure that the DNS settings are correct on VDA and DDC, and both the computers can resolve each other by DNS name and reverse lookups. Use the XDPing tool, downloadable from the Knowledge Center article CTX123278 – XDPing Tool to further troubleshoot.

  5. Check that the Time is in sync between the VDA and DDC are correct.

    For further troubleshooting, see Troubleshooting Virtual Desktop AgentRegistration with Controllers in XenDesktop.

Single Forest with Multiple Domains or Single Forest with Multiple Domains with shortcut trusts

The following two diagrams illustrate a XenDesktop deployment in a single forest with multiple domains and a Single Forest with multiple domains with shortcut trusts – where the DDC, VDA, and Users are all based in different domains.

The following is the illustration for Multiple Domains:

User-added image

The following is an illustration for Multiple Domains with short cut trusts:

User-added image

Multiple Domains: DDC, Users, and VDA are based in various domains, by default, a bidirectional transitive trust relationship exists between all domains in a forest.

Multiple Domains with short cut trusts: DDC, Users, and VDA are based in various domains but at two-way shortcut, trust has been manually created between the DDC domain and the VDA domain. Typically, shortcut trusts are used in a complex forest where it can take time to traverse between all domains for authentication. By adding a shortcut trusts, it shortens the trust path to improve the speed of user authentication.

For successful registration of the VDA with the DDC, the following should be configured correctly. DNS Forward/Reverse Lookup Zones are in place and configured on the relevant DNS servers. For further troubleshooting of VDAs not registering, see Following is a list to check if VDA is unable to register with the DDC: mentioned in the Simple Single Deployment section.

Multiple Forests with 2 way or 1 way trusts (external trusts or forest trusts)

The following diagram illustrates XenDesktop deployment in a Multi-Forest Deployment. This is where the DDC is in a different Active Directory forest and the end users and desktops can be either in the same forest or in a separate Active Directory forest.

Note: For Forest trusts, both Forests must be in Win2003 Forest Functional Level.

User-added image

The preceding illustration shows two separate Active Directory forest with a two-way forest trust. DDC and Users are in the same forest (parent.local) but the VDAs are located in different forest (parent2.local).

For successful VDA registration with the DDC, the following must be configured correctly:

DNS, for name and reverse lookups. Depending on the approach taken, the use of DNS Forwarders and Conditional Forwarders, Forward /Reverse lookup zones and Stub zones are all acceptable for name lookup/resolution. As an example, in the preceding illustration, on the DNS server for Parent.local, a Secondary Forward Lookup Zone and a Reverse Lookup zone for Parent2.local has been added and similarly the opposite has been done on the Parent2.local. This means that the DDC should now be able to resolve the VDA by name and IP and the VDA resolves the DDC by name and IP address.

See Managing a Forward Lookup Zone for information on managing Lookup Zones.

On the Desktop Delivery Controller, enable the following registry value on the DDC. This enables support for VDAs, which are located in separate forests: HKEY_LOCAL_MACHINESoftwareCitrixDesktopServerSupportMultipleForest (REG_DWORD)

User-added image

To enable VDAs located in separate forests; this value must be present and set to 1.

After changing the SupportMultipleForest value, you must restart the Citrix Broker Service for the changes to have an effect.

On the Virtual Desktop Agent, enable the following registry value on the VDA to enable support for DDCs located in a separate forest.

  • For a 32-bit VDA: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentSupportMultipleForest (REG_DWORD)

  • For a 64-bit VDA: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentSupportMultipleForest (REG_DWORD)

To enable support for DDCs located in a separate forest; this value must be present and set to 1.

Note: The next step is only required if External Trusts are only being used.

  1. If the Active Directory FQDN does not match the DNS FQDN or if the domain where the DDC resides has a different NetBIOS name to that of the Active Directory FQDN, you must add the following registry key on the Virtual Desktop Agent machine.
    • For a 32-bit VDA: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentListOfSIDs
    • For a 64-bit VDA: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentListOfSIDs
    • User-added image

The ListOfSIDs registry key contains the DOMAIN SID of the DDC. By using this key, DNS lookups are using the true DNS name of the DDC.

To obtain the correct domain SID of the DDC, the domain SID can be found by using a tool such as ADExplorer from sysinternals or by using the XDPingtool.

Note: You must restart the Citrix Desktop Service for the changes to have an effect.

Multiple Forests with One-Way Selective trusts

The following diagram illustrates XenDesktop deployment in a Multi-Forest Deployment using One-way Selective Trusts. The DDC is in a different Active Directory forest and the end users and existing VDAs (created either manually or through an alternative method) are in a separate Active Directory forest. In a one-way selective trust, automatic creation of Virtual Machines through DDC will fail, because of authentication issues.

For this example, the NetBIOS and FQDN are different in each Forest and domain.

Note: For One-Way Selective trusts, both Forests must be in Win2003 Forest Functional Level or above.

User-added image

Selective authentication is used in environments where users are explicitly granted/ allowed to authenticate to servers and resources on the trusting domain. This method gives domain administrators control on what rights users can be given to access services on the trusting domain. See Enable Selective Authentication over a Forest Trust for more information on Selective trusts.

Configure the following for successful registration of the VDA with the DDC:

  1. DNS for name and reverse lookups. Depending on the approach taken, the use of DNS Forwarders and Conditional forwarders, Forward/Reverse lookup zones, and Stub zones are all acceptable for name lookup/resolution.

  2. Create the Selective trust on the relevant Domain Controllers.

  3. Follow steps provided in the Multiple Forests with trusts (External trusts – NTLM or Forest trusts Kerberos) section.

  4. The VDAs must be granted authentication access to the DDC. This is done through Active Directory Computer and Users snap-in.

    Note: VDAs can be added to a group to make management easier (granting rights). This is recommended.

    a) In Active Directory Computers and Users, browse to the location of the DDCs.

    b) Right-click DDC and click Properties.

    c) Click the Security tab.

    d) Click Add and click Locations to change the domain to where the VDAs reside.

    e) Click on Advanced, and click on Object Types. Choose ‘Computers’

    f) Select all the relevant VDA or Group (recommended) and click OK.

    g) Select the VDA’s or Group and give the rights – Read and Allowed to authenticate, as displayed in the following screen shot:

      1. User-added image

  5. On the DDC, select an Existing Catalog and create a relevant Assignment. When done, the Virtual Machines should show in a Ready State, as displayed in the following screen shot:

    User-added image

For further troubleshooting of VDA not registering, see Following is a list to check if VDA is unable to register with the DDC section.


  • No Related Posts

NTP not synchronized on Advanced Threat Protection

I need a solution

HI Team,

After running the “status_check” command in Symantec ATP’s CLI i am getting following message:

NTP                                             NOT synchronized!
                                                Please fix NTP configuration, else
                                                the appliance may not function properly.

We are using  Domain Controller (DC) as NTP server. 

As per the symantec KB article:…

if the time servers is a DC, change


LocalClockDispersion from 10 to 0.

I have cheked the same with DC team but they informed me that only Symantec ATP team only reported the error.

No other applications or services team has reported the issue.

DC team can not do the aforementioned changes in their DC server cause it might impact many applications,services and servers in environment.

Can you guys help me with workaround to fix this issue??

Quick response will be appreciated. 



  • No Related Posts

MCS created pooled Windows 10 machines get the wrong logon server

Under certain conditions, when you create MCS pooled random Windows 10 machines, they might point to wrong domain controller as the logon server. This will lead to delayed user logon and GPO applications might take longer than expected.

On further investigation, you would observe the following registry key being created on MCS provisioned machines.



  • No Related Posts

Change Password Option in StoreFront Not Shown, Available Only for Admins

Set permissions on AD following this article

The users AD accounts need READ access to the following objects:

  • Domain Root Object: It looks up the primary domain of the Domain Controller and opens the domain for reading, which in turn opens the AD object for the domain, like DC=contoso,dc=com.
  • Builtin container: This is the root object of the builtin domain. It is opened as the caller wants to verify its existence. Thus the caller needs read access to the container CN=Builtin,DC=contoso,dc=com.
  • SAM server object: This object stores general permissions about general SAM account access and enumeration. It will be used on certain calls only. The object name is cn=server,cn=system,DC=contoso,dc=com.

As stated in the Microsoft article “In most Active Directory domains, permissions to these objects are granted based on the membership in generic groups like “Authenticated Users”, “Everyone” or the “Pre-Windows 2000 Compatible Access” group”. If possible these should be restored their Read permissions and/or the users accounts added back to these groups.

If that is not possible

  1. In Active Directory Users and Computers select View -> Advanced Features
  2. Create a new AD group containing the users that need access to the Change Password feature
  3. Right click the domain root object -> Properties -> Security
  4. Add the new AD group with Read permissions -> Apply -> OK
  5. Right click the Builtin container -> Properties -> Security
  6. Add the new AD group with Read permissions -> Apply -> OK
  7. Select the System Container -> Right click the Server samServer object -> Properties -> Security
  8. Add the new AD group with Read permissions -> Apply -> OK


  • No Related Posts

Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part II

EMC logo

Virtualized Active Directory is ready for Primetime, Part II!

In the first of this two-part blog series, I discussed how virtualization-first is the new normal and fully supported; and elaborated on best practices for Active Directory availability, achieving integrity in virtual environments, and making AD confidential and tamper-proof.

In this second installment, I’ll discuss the elements of time in Active Directory, touch on replication, latency and convergence; the preventing and mediating lingering objects, cloning and of much relevance, preparedness for Disaster Recovery.

Proper Time with Virtualized Active Directory Domain Controllers (AD DC)

Time in virtual machines can easily drift if they are not receiving constant and consistent time cycles. Windows operating systems keep time based on interrupt timers set by CPU clock cycles. In a VMware ESXi host with multiple virtual machines, CPU cycles are not allocated to idle virtual machines.

To plan for an Active Directory implementation, you must carefully consider the most effective way of providing accurate time to domain controllers and understand the relationship between the time source used by clients, member servers, and domain controllers.

The Domain Controller with the PDC Emulator role for the forest root domain ultimately becomes the “master” timeserver for the forest – the root time server for synchronizing the clocks of all Windows computers in the forest. You can configure the PDC to use an external source to set its time. By modifying the defaults of this domain controller’s role to synchronize with an alternative external stratum 1 time source, you can ensure that all other DCs and workstations within the domain are accurate.

Why Time Synchronization Is Important in Active Directory

Every domain-joined device is affected by time!

Ideally, all computer clocks in an AD DS domain are synchronized with the time of an authoritative computer. Many factors can affect time synchronization on a network. The following factors often affect the accuracy of synchronization in AD DS:

  • Network conditions
  • The accuracy of the computer’s hardware clock
  • The amount of CPU and network resources available to the Windows Time service

Prior to Windows Server 2016, the W32Time service was not designed to meet time-sensitive application needs. Updates to Windows Server 2016 allow you to implement a solution for 1ms accuracy in your domain.

Figure 1: How Time Synchronization Works in Virtualized Environments

See Microsoft’s How the Windows Time Service Works for more information.

How Synchronization Works in Virtualized Environments

An AD DS forest has a predetermined time synchronization hierarchy. The Windows Time service synchronizes time between computers within the hierarchy, with the most accurate reference clocks at the top. If more than one time source is configured on a computer, Windows Time uses NTP algorithms to select the best time source from the configured sources based on the computer’s ability to synchronize with that time source. The Windows Time service does not support network synchronization from broadcast or multicast peers.

Replication, Latency and Convergence

Eventually, changes must converge in a multi-master replication model…

The Active Directory database is replicated between domain controllers. The data replicated between controllers called ‘data’ are also called ‘naming context.’ Only the changes are replicated, once a domain controller has been established. Active Directory uses a multi-master model; changes can be made on any controller and the changes are sent to all other controllers. The replication path in Active Directory forms a ring which adds reliability to the replication.

Latency is the required time for all updates to be completed throughout all domain controllers on the network domain or forest.

Convergence is the state at which all domain controllers have the same replica contents of the Active Directory database.

Figure 2: How Active Directory Replication Works

For more information on Replication, Latency and Convergence, see Microsoft’s Detecting and Avoiding Replication Latency.”

Preventing and Remediating Lingering Objects

Don’t revert to snapshot or restore backups beyond the TSL.

Lingering objects are objects in Active Directory that have been created, replicated, deleted, and then garbage collected on at least the Domain Controller that originated the deletion but still exist as live objects on one or more DCs in the same forest. Lingering object removal has traditionally required lengthy cleanup sessions using various tools, such as the Lingering Objects Liquidator (LoL).

Dominant Causes of Lingering Objects

  1. Long-term replication failures

While knowledge of creates and modifies are persisted in Active Directory forever, replication partners must inbound replicate knowledge of deleted objects within a rolling Tombstone Lifetime (TSL) # of days (default 60 or 180 days depending on what OS version created your AD forest). For this reason, it’s important to keep your DCs online and replicating all partitions between all partners within a rolling TSL # of days. Tools like REPADMIN /SHOWREPL * /CSV, REPADMIN /REPLSUM and AD Replication Status should be used to continually identify and resolve replication errors in your AD forest.

  1. Time jumps

System time jump more than TSL # of days in the past or future can cause deleted objects to be prematurely garbage collected before all DCs have inbound replicated knowledge of all deletes. The protection against this is to ensure that:

  • The forest root PDC is continually configured with a reference time source (including following FSMO transfers).
  • All other DCs in the forest are configured to use NT5DS hierarchy.
  • Time rollback and roll-forward protection has been enabled via the maxnegphasecorrection and maxposphasecorrection registry settings or their policy-based equivalents.
  • The importance of configuring safeguards can’t be stressed enough.
  1. USN rollbacks

USN rollbacks are caused when the contents of an Active Directory database move back in time via an unsupported restore. Root causes for USN Rollbacks include:

  • Manually copying previous version of the database into place when the DC is offline.
  • P2V conversions in multi-domain forests.
  • Snapshot restores of physical and especially virtual DCs. For virtual environments, both the virtual host environment AND the underlying guest DCs should be compatible with VM Generation ID. Windows Server 2012 or later, and vSphere 5.0 Update 2 or later, support this feature.
  • Events, errors and symptoms that indicate you have lingering objects.

Figure 3: USN Rollbacks – How Snapshots Can Wreak Havoc on Active Directory


You should always use a test environment before deploying the clones to your organization’s network.

DC Cloning enables fast, safer Domain Controller provisioning through clone operation.

When you create the first domain controller in your organization, you are also creating the first domain, the first forest, and the first site. It is the domain controller, through group policy, that manages the collection of resources, computers, and user accounts in your organization.

Active Directory Disaster Recovery Plan: It’s a Must

Build, test, and maintain an Active Directory Disaster Recovery Plan!

AD is indisputably one of an organization’s most critical pieces of software plumbing and in the event of a catastrophe – the loss of a domain or forest – its recovery is a monumental task. You can use Site Recovery to create a disaster recovery plan for Active Directory.

Microsoft Active Directory Disaster Recovery Plan is an extensive document; a set of high-level procedures and guidelines that must be extensively customized for your environment and serves as a vital point of reference when determining root cause and how to proceed with recovery with Microsoft Support.


There are several excellent reasons for virtualizing Windows Active Directory. The release of Windows Server 2012 and its virtualization-safe features and support for rapid domain controller deployment alleviates many of the legitimate concerns that administrators have about virtualizing AD DS. VMware® vSphere® and our recommended best practices also help achieve 100 percent virtualization of AD DS.

Please reach out to your Dell EMC representative or checkout Dell EMC Consulting Services to learn how we can help you with virtualizing AD DS or leave me a comment below and I’ll be happy to respond back to you.


Virtualizing a Windows Active Directory Domain Infrastructure

Related Blog

Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part I

The post Best Practices for Virtualizing Active Directory Domain Controllers (AD DC), Part II appeared first on InFocus Blog | Dell EMC Services.

Update your feed preferences





submit to reddit


  • No Related Posts

Virtual Desktops Appear as “Not Registered” in the Console

To resolve the issue, grant the logon right, Access this computer from the network to the Delivery Controller machine account(s).

This can be modified directly on the VDA (recommended for testing):

  1. To edit the policy directly on the VDA, use Local Computer Policy editor (MMC, then add the Snap-In Local Computer Policy.)
  2. The policy is located in Computer Configuration –>Windows Settings –>Security Settings –>Local Policies –>User Rights Assignment
  3. Locate “Access this computer from the network”
  4. Click ‘Add User or Group’. Change the Object Types to include “Computers”.
  5. Type the names of the Delivery Controller(s). Click ‘Check Names’. Click OK to save the change. There will be several warnings.

Once this is determined to resolve the OU-based registration issue, policy can be applied to all the VDA’s by completing one of the following tasks:

  • Apply a group policy from the domain controller either to the domain as a whole or to an Organizational Unit containing the Virtual Desktops for the XenDesktop farm.

User-added image


7018092: Active Directory Password Checkout – LDAP modify failed, error 53 (Server is unwilling to perform)

This document (7018092) is provided subject to the disclaimer at the end of this document.


NetIQ Privileged Account Manager

Microsoft Active Directory LDAP


Unable to check-in password with Microsoft Active Directory (AD) LDAP

Password Checkout for Active Directory Application over LDAP is not working

Using the checked-out password reports invalid credentials, account name / password

MyAccess reports Failed Check-in to user

The following appears in the Debug unifid.log when attempting check-in:

Warning, LDAP modify failed, error 53 (Server is unwilling to perform)

Error, LDAP modify failed – 182553


Microsoft Active Directory (AD) may have requirements that are preventing the password change from taking place. This error means the destination LDAP server is not allowing this password change to go through. While there might several reasons for this error to be returned from the LDAP server, here are some common Microsoft Active Directory explanations / requirements:

  1. Microsoft AD may impose some strength requirements on the password. In order to conform to these requirements, a password policy must be created and assigned to the application account domain in the Enterprise Credential Vault. For more details about this process, please refer to documentation:
  • Microsoft AD may only accept password changes over secure connections (SSL, ldap port 636). Verify the Active Directory Application Account Domain in the Enterprise Credential Vault has been configured to have SSL enabled and to use the correct port.

    Note: By default, LDAPS://connections use port 636 for SSL.

  • Microsoft AD requires that the client must bind as a user with sufficient permissions to modify another user’s password. In this case, the proxy credential provided to PAM in the AD LDAP Account Domain of the Enterprise Credential Vault must have sufficient permissions to modify another user’s password. According to Microsoft, “the password is stored in the AD and LDS database on a user object in the unicodePwd attribute.”

  • Cause

    Microsoft Active Directory (AD) is denying the LDAP modify request because the request violates certain requirements / criteria determined by the Microsoft AD Domain Controller.

    Additional Information

    For more information from Microsoft on these certain restrictions, please refer to How to change a Windows Active Directory and LDS user password through LDAP.


    This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.


    7023292: How to use DRA when remote access to the Windows DC SAM is restricted

    This document (7023292) is provided subject to the disclaimer at the end of this document.


    NetIQ Directory and Resource Administrator 9.1.x

    NetIQ Directory and Resource Administrator 9.2.x

    Microsoft Windows Domain Controller 2016


    Microsoft Windows GPO settings provide the option of restricting remote access to any member server, or domain controller’s Security Account Manager’s (SAM) database. This database contains security details for users and groups within the local Windows OS or Domain Controller. Through the use of a GPO setting, remote access into the database can be restricted.

    If this security lock down is in place, the DRA server might return an error when attempting to set a domain access account. DRA will fail to determine if the access account has the necessary AD rights.


    Modify the Security Descriptor to include the AD account used for the Domain Access account within the managed domain properties of DRA. Enabling this setting will allow the account(s) listed within the Security descriptor field the ability to make remote queries to the SAM. This ability is not restricted by remote client.


    NetIQ Directory and Resource Administrator (DRA) requires some level of Administrative access to each Active Directory Domain or Member Server managed by DRA. The DRA Server will validate this access by checking the SAM of the Member Server or AD Domain Controller. If there are no security details returned back to DRA, the DRA Server will report an error. This access check occurs at multiple times within the regular operation of DRA. The most common occurrences are:

    Adding a new managed domain

    Accounts Cache Refresh

    Domain Configuration Refresh

    When the Microsoft GPO setting for: Network access: Restrict clients allowed to make remote calls to SAM, the default value used the Security descriptor field is set to Built-InAdministrators. When the DRA Domain Access account is not a direct or indirect member of the Built-InAdministrators group, requests made to the SAM will fail. This failure will cause DRA to fail as well.

    Additional Information

    More information on this GPO setting can be found at: .

    The most common use of this GPO is with Windows 2016 AD Domains. Other domain functional levels can still apply the GPO as well. Specific details about the Domain and Computer requirements for the GPO application can be found within the Microsoft Documentation listed above.

    This GPO setting will not affect a Domain Access account within membership in the AD Domain Admins group. This group is a member of the built-in Administrators group within AD.


    This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.


    Re: Some DNS servers configured for the DNS client of NAS server are not reachable.

    My UNITY EMC is presenting the following errors every day, the DNS are unstable, they fail for a few minutes and they are re-established later.

    These are the error messages:

    The NAS server XXXXXXXXXX in the domain can’t reach any Domain Controller.

    For the NAS server XXXXXXXXXX in the domain MYDOMAIN, the DC EKTW08DCO-AJ01 has the following error: compname XXXXXXXXXXX DC=EKTW08DCO-AJ01 Step=’Open NETLOGON Secure Channel’ ‘NETLOGON’ ‘DC NETLOGON pipe failure:Access denied’

    the network department has monitored the link between storage and DNS, but the cause has not been identified.

    Could you help me, please?