none
cross-domain GPO performance RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I'm trying to figure out why it is claimed that cross-domain GPO is not recommended due to performance concerns.  The primary source seems to be this blog:

    Group Policy Basics – Part 1: Understanding the Structure of a Group Policy Object

    If \\Domain1DC\sysvol & \\Domain2DC\sysvol are on the same vlan in the same data center and user in Domain1 has a policy (or several) linked from Domain2, I'm having a hard time measuring the performance difference.  The org actually has users in Domains 1-11 and the real trouble was keeping the user policies consistent (all of the workstations are now in Domain1 now, so computer policies are no problem).

    I guess the question is, why can it be a very slow process?

    >   In the case of a cross-domain GPO, the client will need to pull content from a DC in the neighboring domain which can be a very slow process.  For this reason, cross-domain GPOs are not generally recommended.

    Thanks,
    J

    Joseph M. Durnal MCM: Exchange 2010 MCITP: Enterprise Messaging Administrator, Exchange 2010 MCITP: Enterprise Messaging Administrator, MCITP: Enterprise Administrator

    Thursday, October 10, 2019 9:48 PM
    |

Answers

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote

    Hi,

    "If the cross-domain are configured, the client need to pull content from a DC in the neighboring domain "that means, the client need to ask the local domain DC for authentication , then the DC in the local domain will forward the authentication to the DC neighboring domain. The authentication traffic will increase.

    If you want to make the whole process clear , the GPSVC log  can be considered. For more information you can refer to the following link:

     https://blogs.technet.microsoft.com/askds/2015/04/17/a-treatise-on-group-policy-troubleshootingnow-with-gpsvc-log-analysis/

     

    Best Regards,

    Fan

     


    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, October 11, 2019 5:20 AM
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

     

    Just checking in to see if the information provided was helpful. Please let us know if you would like further assistance.

     

    Best Regards,

    Fan

    Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, October 14, 2019 8:12 AM
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

     

    Hi,

     

    Please remember mark all the useful replies as answer, it would be helpful to anyone who encounters similar issues.

     

    Best Regards,

     

    William

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, October 18, 2019 9:02 AM
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    "If the cross-domain are configured, the client need to pull content from a DC in the neighboring domain "that means, the client need to ask the local domain DC for authentication , then the DC in the local domain will forward the authentication to the DC neighboring domain. The authentication traffic will increase.

    If you want to make the whole process clear , the GPSVC log  can be considered. For more information you can refer to the following link:

     https://blogs.technet.microsoft.com/askds/2015/04/17/a-treatise-on-group-policy-troubleshootingnow-with-gpsvc-log-analysis/

     

    Best Regards,

    Fan

     

    I see - I suppose I discounted the cross domain authentication in our environment as many other resources are located in the trusting domain.  There is a long running migration to eventually move all the users to that domain but it has become a very long running project.

    Joseph M. Durnal MCM: Exchange 2010 MCITP: Enterprise Messaging Administrator, Exchange 2010 MCITP: Enterprise Messaging Administrator, MCITP: Enterprise Administrator

    Tuesday, October 22, 2019 5:16 PM
    |